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METHOD FOR DELIVERING SEPARATE 
DESIGN AND CONTENT IN A MULTIMEDIA 
PUBLISHING SYSTEM 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to multimedia publishing 
systems and more particularly, to a system and method for 
publishing and viewing titles which include separate content 
and layouts. 

2. Description of the Related Technology 

Microsoft Network, Internet, Compuserve, Prodigy, and 
America On-line are examples of on-line networks. End 
users typically access these networks using a microcomputer 
equipped with a modem. During an on-line session, a user 
can use a variety of information-related services and com- 
munications services, including news services, weather 
services, bulletin board services, E-mail, and the like. 

While on-line services are becoming increasingly 
popular, today's on-line applications are still in their infancy. 
In fact, significant problems continue to block independent 
content providers or publishers from deploying the type of 
sophisticated and compelling services that are necessary to 
provide a sustainable on-line business. At the same time, 
providers of existing on-line services are working to find the 
right technical business model and usability solutions that 
will promote acceptance beyond just an early-adopter audi- 
ence. 

In any large city, it is impossible for a single individual to 
keep up with the activities and events unfolding in the 
community. Consequently, people turn to writers, reporters, 
editors, critics, and others, for help in understanding and 
structuring the information available. In a related trend, 
broadcast media are increasingly unable to satisfy the needs 
of a diverse populace. Consequently, in most markets, 
narrowcast media (media that have tailored and distributed 
their content to smaller, well defined audiences) have 
become increasingly popular and profitable. In the on-line 
community this trend will be correspondingly more impor- 
tant. 

One problem content providers encounter when creating 
applications for the mass market is the diverse audience. For 
example, some customers will be interested in games, some 
in, business, some in computer technology, and some in 
movies. What information should content providers deliver 
to keep their customers satisfied? What is needed is a system 
that enables a content provider to create applications that 
blend the content provider's editorial voice with individual 
customization. For example, from within a particular 
application, a customer could indicate an interest in the is 
computer business and/or classical music, and be able to 
acquire additional information focused on these areas. 
Similarly, an on-line publication might automatically syn- 
thesize and prioritize content based on different consumer 
preferences. 

There are several significant hurdles facing the on-line 
industry. These problems include: 

Quality. Today's on-line offerings lack the sophistication 
required to attract and maintain a loyal customer following. 
Today, the technology simply does not exist to create truly 
compelling applications and services with rich, interactive 
multimedia features, while at the same time delivering these 
applications and services over low-bandwidth connections. 
What is needed is a system that overcomes these limitations, 
removing existing design constraints and allowing content 
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providers to easily deploy and maintain a new generation of 
on-fine multimedia applications. 

Control. Existing on-line services do not provide content 
providers complete control over the creation of their on-line 
5 applications and services. For example, application creation, 
distribution, customer relationships, advertising and pricing 
are most often controlled not by the content provider, but 
rather by the on-line service itself. In addition, no existing 
on- fine service or the Internet's World -Wide- Web allow 
to content providers to create unique, compelling and highly 
branded applications. What is needed is a system that 
enables content providers to create and develop their own 
unique brands, customer and advertiser relations, and busi- 
ness models. Content providers could then make their 
15 branded products the focus of customer interactions to the 
point that customers often may not be aware they are using 
an on-line service. 

Cost. Providers of on-line services are finding that the 
tools to effectively manage the process of creating, 
deploying, and maintaining on-line applications and services 
are limited. Because existing tools do not fully meet the new 
demands of the on-line world, the ongoing cost of main- 
taining on-line applications can be prohibitive. What is 
needed is a system that is specifically designed to support 
existing business processes and industry standard informa- 
tion interchange formats. Content providers could then 
create on-line multimedia titles rapidly and with little pro- 
duction overhead. 

Additional concerns for an on-line service include 
flexibility, automatic delivery of applications to the 
customer, integrating on-line information browsing with 
agent-based information gathering, customized content, cus- 
tomer receiving-device independence, support for standards, 
inclusion of advertising, and a familiar production process. 

As more content providers move from the realm of print 
publishing into the on-line world, they are increasingly 
alarmed by the real constraints placed upon their ability to 
create an on-line title that is as visually rich and polished as 
they were able to create on paper. Further, they would like 
to take advantage of the multimedia capabilities of today's 
personal computers to enhance their titles well beyond their 
paper versions. Specific roadblocks they encounter are: 

■ In the real world, content authors are rarely skilled 
45 graphic designers (and vice versa), yet existing multi- 
media authoring tools require the same person to do 
both jobs. At the very least, the same tool is generally 
used for both jobs, creating an opportunity for errors to 
be introduced. 

50 ■ Each authored piece of content must go through the 
layout process before it is published, a time and human- 
labor-intensive process that constrains a publisher's 
ability to provide "real-time" information that is also 
visually compelling. Also, depending on exactly where 

55 a new piece of content is to appear in a publication, 
other parts of the publication that were previously 
downloaded may no longer be valid and may need to be 
re-composed and the new version downloaded. 

■ Graphics and multimedia objects are huge, and take 
60 long periods of time to download to the average cus- 
tomer's or consumer's personal computer across a 
typical modem. Traditional approaches to visually rich 
on-line publishing require rendering the screen images 
on the publisher's machine or on the on-line service's 

65 mainframe, which then results in the download of 
fully- rendered graphics, the worst-case scenario for 
download time. In this context, rendering refers to the 



40 
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creation of a bitmap of a display screen in memory 
prior to displaying the screen. In addition, while many 
titles contain repeated text and/or pictures, traditional 
on-line publishing methods require downloading the 
text or image again each time it appears in a new 5 
screen. 

■ The personal computers that consumers are buying 
today contain sophisticated processors which can do a 
remarkably good job of rendering rich, visually com- 
pelling titles. However, the current approaches to 1Q 
building, delivering and viewing rich, multimedia titles 
do not utilize the rendering capability of the consum- 
er's machine. 

Content providers would like to support different form 
factors for displaying the same content — for example, a 
personal digital assistant (PDA) or a 1024x768 pixel screen. 15 
Rich, visually compelling titles would have completely 
different layouts for display on these two different systems. 

Content providers might also wish to create both "full" 
and "lite" versions of their titles, where the "lite" version 
contains less content for a smaller price. 20 

Additionally, accessibility concerns might require that a 
content provider create a "large print" title with a completely 
different layout, or a title with larger controls for persons 
with less fine motor control of their hands. 

Traditionally, supporting different form factors, "lite" 25 
versions, and "large print" titles has required creating a 
separate copy of the content for each title. Doing so adds 
additional storage overhead to the system, as well as requir- 
ing more work to keep the copies identical when updates 
occur. 30 

Many different systems exist for publishing documents on 
a computer system. These systems are used to, for example, 
create newsletters or brochures to promote a particular 
company. In addition, publications can be used to dissemi- 
nate information to a variety of customers. A number of 35 
programs exist for allowing a user to design complicated 
layouts for a particular application. Well-known programs 
such as Microsoft Publisher®, Ventura Publisher®, 
PageMaker®, and PrintShop® help a user to produce attrac- 
tive newsletters and brochures. 40 

These publication systems let the user define particular 
regions of every page for a specific purpose. For example, 
the user can place a graphic frame that runs along the top of 
the page to hold a particular image. Such an image may 
include the title of the newsletter or another related aspect of 45 
the newsletter. In a similar way, the user may define other 
areas of the first page to include one or more text frames for 
holding text-based information such as the words from 
particular story. The user designs the text frame to have 
certain properties, such as height, width, background color, 50 
foreground color and other such properties so that the text 
becomes attractively formatted for the customer. In addition, 
the user can format the text information within the text frame 
to have desired font and paragraph characteristics. For 
example, the user can highlight the characters within the text 55 
frame and define that font to be, for example, bold-faced. 
The user can also choose to only apply a character format to 
specific words or paragraphs within a text frame. 

After defining an initial text frame in these publishing 
systems, the user can define additional text frames on the 60 
same page. For example, one text frame may hold the title 
of a story whereas the next text frame holds the name of the 
author and the text of the story. Although this layout is 
straightforward to prepare, it is also very difficult to modify 
once it has been produced. 65 

Another category of publication systems include software 
for electronically publishing stories across on-line networks 



such as CompuServe, America On-Line, or the Internet. 
Most of these systems create and display stories that are 
formatted in a Standard Generalized Markup Language 
(SGML) or Hypertext Markup Language (HTML). Both the 
HTML and SGML are standards for tagging text in docu- 
ments to be displayed in an on-line network. Documents that 
are formatted in HTML or SGML can be viewed by several 
widely distributed browsers such as Mosaic and NetScape 
for the Internet. These browser programs read SGML and 
HTML Jagged_dacuments and display them with proper 
formatting. However, the for matting informatio n is stored 
with the brow ser and is not d istributed by the publisher. 

Several programs exist fo^Sfpdudnj^ocuments that are 
tagged in either the SGML anoTT^ML format. Programs 
such as InterleaPs Wo rid View 2 allow a user to create an 
SGML document with, for instance, bold -face text and 
hyperlinks to other documents. Once a document has been 
saved in an SGML format, it can be read by either the 
Mosaic or NetScape browser. Unfortunately, all of the 
formatting commands for text or graphics in an SGML or 
HTML document are embedded, within the document. The 
Mosaic or NetScape browsers dn not reformat these ta gged 
documents, but rather only display the commands embedded 
in the SGML or HTML documents to a user. For this reason, 
the desig ners that produce the SGML and HTML docum ents 
must _add formatting commands to every new do cument. In 
addition, there is little flexibility to change the document's 
formatting once the tagged document has been produced. 
Therefore, the p rocess of creating documents for djs play 
us ing SGMLjo rJjUMI^S-V£Quneifi dent for the docum ent 
designer. 

Other commercially available software programs for pro- 
ducing on-line publications are available in the marketplace. 
One type of electronic publisher that generates its own 
specific format of text while retaining the specific layout of 
the document is the Adobe Acrobat™ software package. 
Acrobat™ reads and stores documents in a specialized 
format known as the Portable Document Format, (PDF) for 
use on the Internet. Other electronic publishing programs are 
produced by Interleaf, Inc. (Waltham, Mass.), Farallon Com- 
puting (Alameda, Calif.) and Common Ground Software 
(Belmont, Calif.). 

Another on-line information system is described in U.S. 
Pat. No. 5,347,632 by Filepp et al. This patent discusses an 
interactive computer system network which enables a user to 
display news information and perform transactional services 
through a personal computer. However, in the Filepp system, 
the news information is integrated into display regions. 

The invention described in U.S. Pat. No. 5,347,632 
includes procedures for formulating objects that have been 
specially structured to incl ude display data, control da ta and 
program instructio ns. Unfortunately, this system does not 
provide a separation of the content being displayed from the 
design. Therefore, the same design layout cannot be shared 
aniol5g"di sparate pieces of conte nt. 

The content displayed in this system is therefore difficult 
to modify because new design layouts must be transmitted 
to the users acr oss slow communications lines for e very 
pi ece of mfarjoaiion viewed on th e computer monitor. If the 
content of the information was separated from the design 
layout at publication time, then design layout objects could 
reside locally cm _the_ user's computer and be available 
wh enever required by a soecific~^iece "qf content. These 
disadvantages are overcome by the present invention. 

SUMMARY OF THE INVENTION 

This invention is a multimedia publishing system 
designed for creating publicationsJhat include components 
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for design, authoring, distribution, viewing, search, FIG. 3 is a diagram of an exemplary on-line system for 

personalization, and billing of on-line services. The major publication storage and distribution. 

benefit of such a system is efficient distribution, content p] G 4 ^ 51ock diagram of a hierarchy of containers or 

Polished segarajely from the layout, separation of foWer for a luralit of publishere using me system of FIGS 

re sponsibilities, hardware independence, automa tically 5 j aQ£ j 2 

place d content and personalized titles" " 

Efficient distribution is achieved by separating the content F * G * 5 ! s a ove ™ ew flow °f MPS Processes 

an d design which enables transmission of high-quality t itles P erformed usm S ^ system of FIGS. 1 and 2. 

over low-speed communications links subject to loss of FIG. 6 is an exemplar^sgieqn display of one page of a 

connectivity. Since the design of many titles remains rea- 1Q title as displayed by thc ^viewer^ f FIG. 2. 

sonably static while the content changes on a regular basis, FIG. 7 is an exemplary screen display of the parts of the 

caching the layout designs minimizes the transmission of content and layout for the title displayed in FIG. 6. 

redundant data and opti mized the bandwidth u se. Typically, FIG. 8 is a block diagram of the interaction of page 

content is transmitted quickly since it consists of tagged layouts, controls, style sheet and content objects at the 

components, not the actual pages and controls themselves. 15 viewer of FIG. 2. 

This significantly reduces transmission times for download- FIG. 9 is a diagram illustrating a query performed by the 

mg a title. Also, when the same content is used more than customer using a "find" dialog on the system shown in 

once in a title, reuse of content is possible, further reducing FIGS. 1 and 2 

the amount of information that must be downloaded. Once tA * ui 1 j- r «i_ * r*. 

# j. l • . • i i j j •* • . . HG. 10 is a block diagram or the major software com- 

the content object is downloaded, it can appear instanta- „ . , ° . r^no ^ j 

i \ , L ... , j . 20 ponents of the system shown in FIGS. 1 and 2. 

neously o n as manyrffa gesJas th e publisher desire s. . 

Si5cIlhe~cont e nt is published separately, this eliminates " G " fl E a d J^T a * uperCOS «" n P onent ° f thc 

«u • 4 .u * *u * * 4 tl i * i_ i . system shown in FIGS. 1 and 2. 

the requirement that the content to be laid out by a designer J 

b efore it can be publish ed. Content can be uploaded to the FIG ' Ub 1S a of an Storage structure used in the 

distribution point and downloaded to consumers' machines 25 implementation of the superCOS of FIG. 11a. 

as soon as the object is completed. Since the rendering is FIG - ^ c k a diagram of a moniker table record and a 

automatically performed on the viewers* computer based GUID map used in the implementation of the superCOS of 

upon the designs in the title's page layouts. FIG. 11a. 

For many content providers, especially those creating 12 is a diagram of a title COS used in the imple- 

on-line publications, the separation of design and content fits 30 mentation of the superCOS of FIG. Ha. 

the existing production process. Many editors have fo und FIG. 13 is a flow diagram of a title creation process 

the amount of production effort required to put content performed on the system shown in FIGS. 1 and 2. 

on-line is inhibiting. With this invention, a design can be FIG. 14 is a flow diagram of a title publishing process 

created only as needed and the changing content is dynami- performed at the publisher's workstation on the system 

callv flowed into the design cached and located in the 35 shown in FIGS. 1 and 2. 

viewer's computer. FIG. 15 is a flow diagram of a title publishing process 

The separation of responsibilities for layout designers and performed at the network on the system shown in FIGS. 2 

content authors is enhanced during the publication process and 3. 

because the graphic designers can work on the title and page FIG. 1« is a diagram of an exemplary object brokering 

layouts, while separately, the authors can create the content 40 scenario of lne process used 00 the the syste * 

ob J ects - shown in FIGS. 2 and 3. 

The tagged content can be displayed with high quality on FIG. 17 is a diagram of an exemplary title tree generated 

a variety of different devic es. For example, a content pro- „ , be vfcwtt . mm m shown ^ 2 

vider can create a title just once, but the title can be viewed „. . ,. . , . ,, . ,, 

on a VGA screen with one column, a printer with many 45 "G. » a diagram of an exemplary view block table 

columSTa small screen PDA, an interactive television viewblock lists used by the viewer component shown in 

(ITV) system, a fax machine, or a notebook computer. * * 

Device independence can represent a significant cost savings FIG * 1Sb is a diagram of an exemplary view block of one 

for content providers, and can help to ensure that a content viewblock list shown in FIG. 18a. 

provider's applications are able to effectively reach a large 50 FIG. 19 is a diagram of another exemplary title tree, 

audience. which includes exemplary parse trees, that is generated at 

The tagged components of a structured story (the ^ viewer component shown in FIG. 2. 

abstracts, headliner, etc.) can be automatically placed in FIGS. 20a and 20b are a flow diagram of a title viewing 

different parts of a title, making it easier for viewers to read process performed by the system of FIGS. 1 and 2. 

and navigate the information. For example, the headline and 55 nG. 21 is a flow diagram of an object retrieval process 

abstract of a story might be displayed on the front page, and performed by the title viewing process defined in FIGS. 20a 

the headline and body of the story might be displayed on an and 20b. 

inside page. This dynamic layout redu ces the effort required n^TAir en nccPDiimnM r\v tuc 

to publish up-to-date , round-the- doc^titfe? DETAILED DESCRIPTION OF THE 



BRIEF DESCRIPTION OF THE DRAWINGS 



60 PREFERRED EMBODIMENTS 



Reference is now made to the drawings wherein like 

FIG. 1 is block diagram of the basic system configuration numerals refer to like parts throughout. For convenience, the 

of the multimedia publishing system (MPS), which is pres- following description will be organized into the following 

ently preferred underlying architecture for the present inven- six principle sections: Acronyms, Advantages of the Multi- 

kon. 65 media Publication System, Multimedia Publishing System 

FIG. 2 is a diagram of the major system components of the Overview, Designer Environment at the Publisher, Viewer at 

MPS shown in FIG. 1. the Customer, and Conclusion. 
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I. ACRONYMS 



The following list of acronyms is provided as a reference 
in reading the remaining sections. 



AVI - 


Advsnced Video Imaging 


BBS - 


Rullph'n RnnrH Swtpm 


MPML - 


Multimedia Publishing Markup Laojzuajsc 


CF- 


Component Forms 


COS - 


Caching Object Store 


DBM - 


Database ManagcmcQt System 


DLL - 


Dynsin ic-l i_nlc Library 


GUID - 


Globally Unique Identifier 


HTML - 


HyperText N^Brkup L?Lngu3^e 


ICP - 


Independent Content Provider 


IM - 


Information Magnet 


IP- 


Information Provider 


LAN - 


Local Area Network 


MP- 


Multimedia Publishing 


MPC- 


Microsoft Network Procedure Call 


MPS- 


Multimedia Publishing System 


MFC - 


Microsoft Foundation Class 


MSN - 


Microsoft Network 


OCX - 


OLE Control 


OFS- 


Object File System 


OLE- 


Object Linking and Embedding 


PDA - 


Personal Digital Assistant 


RPC- 


Remote Procedure Call 


RTF - 


Rich Text Format 


SGML - 


Standard Generalized Markup Language 


VBA- 


Visual Basic for Applications 


WAN - 


Wide Area Network 


WWW - 


World-Wide Web 



10 



15 



20 



35 



30 



II. ADVANTAGES OF THE MULTIMEDIA 
PUBLICATION SYSTEM 

The present invention can perhaps provide the most 
benefit by using an on-line ne twork. Therefore, this and the 
following sections present background information on a 
preferred on-line publication system which is a foundation 
upon which the present invention can reside. 

To enable a new generation of on-line, multimedia 40 
applications, an end-to-end system has been invented for 
developing and using applications and services. The system, 
called the Multimedia Publishing System (MPS or MP 
system), preferably uses the Microsoft Network. As an open, 
turnkey system, the MPS includes components for design, 45 
authoring, distribution, viewing, search, personalization, 
and billing of on-line services and multimedia applications. 
The MP system allows content providers to offer rich, 
interactive multimedia applications and services, providing 
users a compelling and exciting on-line experience. The MP 
system provides the key to overcoming the previously 
described hurdles facing the on-line industry. 

The Microsoft Network removes the primary barriers to 
on-line service use. These barriers include cost, difficult user 
interfaces and lack of inertia. Access to The Microsoft 
Network is provided by Windows 95, the most recent 
version of the Microsoft Windows operating system thereby 
making it accessible to millions of customers. The Microsoft 
Network is designed to make accessing electronic informa- 
tion easy and inexpensive for any user of Windows 95. 

In the MP system, Independent Content Providers (ICPs), 
also known as publishers, supply the system with stories, 
publications, newspapers, sounds, graphics movies and 
much more. The MP system is designed to take projects (e.g. 
stories, publications, and so forth) produced by the publish- 
ers and make them accessible to millions of users on the 
Microsoft Network. Thus, the basic components of the MP 



50 



60 



system are a project designer com ponent, a public distribu- 
tion site, and Qviewer compone n). These components of the 
MP system are described in detail below. 

One unique concept that permeates the MP system is the 
clean separation of c ontent and desig n. In this context, 
content is defined as the actual data that is to be displayed 
to the user. The design of a project is how that information 
gets displayed to the user (e.g., its format on the computer 
screen). An illustrative example would be an electronic 
newspaper, wherein the content is the text and graphics of 
the stories, while the design is the layout and style of that 
data. The design of the_electronic newspaper is what ma kes 
it look like a newspaper on a computCLmonitor^whereas the 
con tent is the data that makes up the designed screens. 

In the MP system, the content and the design are stored as 
separate objects in the public distribution site so that many 
different pieces of content can be viewed with the same 
appearance. An object can be defined as a discrete data item 
or data structure which can be stored in persistent storage or 
in memory. The object may include computer instructions 
for manipulating the data. Once a designer using the project 
designer component aLthe publisher site has created a 
particulaj^pjge^layp,ut„that^ s_ attractive, many pieces of 
content can be viewed from within that layout because of the 
separation of content from design in the MP system. The 
system keeps track of links between a piece of jcxintent and 
its assoc iated page layout, bu t does not actually format the 
data ufthe content with a particular style. 

As will be discussed in more detail below, the designer 
creates proje cts with design and content information fo r a 
pa rticular publisher . Continuing the example from above, a 
project could correspond to an entity that owned a series of 
newspapers and other media businesses. Within each 
project, one or more titles would correspond to the actual 
newspaper. Each title has one or more sections, and can be 
thought of as similar to the sections in a standard, printed 
daily newspaper or other periodical such as a magazine. 

Within each section are pages that define the information 
that is displayed to a single screen on the customer's 
computer visual display. When viewing a particular title, the 
customer will normally look at only one page of information 
at a time. On each p age are controls which contain in struc- 
tio ns for gathering, formatt in g anoHiisplaving the l inked 
co ntent onto the page^ When a customer looks at information 
on^a page that is provided by a publisher, the customer is 
really looking at content that has been formatted within 
pre-defined c ontrol regions on the pa ge. 

One important facet of this invention is the concept of 
viewing the same content objects in many different ways. As 
discussed above, content objects are viewed after hein p; 
for matted by a particular linked control . The control knows 
how to format a particular piece of content by looking at the 
style that has been defined forJhat content by thej lesigner 
an d then compaopg mat s ^V^ e to a linked stvle sheet 
Because each control on a page can have a different asso- 
ciated styles^ee^different controls on the same page can 
each display the same linked content in varying formats. In 
one control, the title might be displayed using a 14 point font 
and bold emphasis, whereas the same piece of content in a 
different control on the page can be displayed in a 12 point 
font and italic emphasis. The ability of each control on a 
page to have its own associated style sheet is a powerful tool 
for the designer to use to format attractive content on a page. 

Unlike prior publishing systems, content (such as text or 
graphics) in the MP system is never reformatted into the 
marked style. The content is only displayed to the user in the 
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chosen style. Therefore, should the designer choose to A. Separation of Design and Content in the Multimedia 

change a particular style, only the style sheet property of that Publishing System 

style needs to be altered. The next time that the content is As discussed above, the MPS architecture maintains a 

d isplayed usi ng the altered style sheeUJhe content will be dean separation between design information and the content 

displayed with tr^o^es of the new style. Other advan- 5 to wh ich that design will be applied. A publisher's collection 

tagesjnci-bengfrts^f the MP s ystem are, discussed in detail of page layoms ^ h tQC form of Qnc or morc titles A ^ 

° w " . , + „ ' is a collection of page layouts, in a particular sequence 

-To provide more detail on the advantages of the MP which relates t0 the order in which pages ^ ^ Wewed 

system, the following section presents an overview of the page layouts deS cribe how the client area of a window 

Multimedia Publishing system. 10 ^ appear when a page ^ rend ered. Rendering refers to the 

III. MULTIMEDIA PUBLISHING SYSTEM creation of a bitmap of a display screen in memory prior to 

OVERVIEW displaying the screen. A complete page layout is created by 

TOssectionpresents an overview of the configuration and J 1 ™* controls 00 \ blank P a S e ^yout where each control 

majoTcomrxme^Tof the preferred Multimedia Publication delineates an area where some piece of content should be 

System. Beginning with a description of the important 15 ^P 1 ^ Settings on each control determine the proper 

concept of separating design (or title layout) and cTntent, P Ia ? to lo< * ' he c ° Dt£ f to * Jap^ycdin that oonhol 

this section continues by discussing the major components content takes thc fo ! m ° f discrete ob J ccts > each of 

and configuration of the MP system. In addition, a descrip- wmch one ^ of ^formation e.g., a story or a 

c t %T * - u* i • t • , . picture. J hese content obi ects are of well-known and pub he 

Uon of the contamer hierarchy is discussed in conjunction , , . F 

with FIGS 1-4 20 formats, and may be created using any tool that 

w' 4 * i- 1 1 t t wno • i j ■ * supports these data formats. Content objects generally do 
The objects uubzed by the MP System include a project; f . c 4 . , : ...r J 

i. c \ a . • n I » i. • . not have formatting mformation encoded withm them, 

title; content folder and, opUonaUy, subfolder; section and, wheQ ^ ^ a ^ ^ ^ _ ^ 

optionally, subsection; wndow; page; control; style sneet; , a ) ^ (he 

content objects, the title and content are 

and various content objects (such as stones, images, audio, „ c ui,vu!j ♦ =+u=,* *u ur a- * -u • * ^ 

c tl ^ f , *ii t i.j- . . 25 published together to the public distribution point. Consum- 

so forth). These objects will be explained in more detail v_ , 0 j , . t , • . . r . , 

, , ■ c i ~t t i*. * i* ers download the title and content objects to their personal 

below in reference to FIGS. 1-7. It is importan to realize whcfe mc Mps viewef ^ us£s * 

lha / fe^ts^^ layouts in the title to compose the content in the visually rich 

puie^memp^u.ca^.^rd disk drive. form designed by tfae 

The natural way of storing related and ordered objects is 30 B System Configuration 

in a data structure, such as an acyclic graph. The presently Referring now to FIG. 1, the basic system configuration of 

preferred way of storing the MP system objects is called a me multimedia publishing system (MPS) 100, which is a 

caching , object store (COS). In the presently preferred MPS, preferred embodiment of the system 100, will now be 

each title corresponds to a COS. There is least one COS at describ ea\ By convention, the term title is used to describe 

the publisher workstation and in each MPS server at the 35 me overall plaii or mstmcUons for assembling the complete 

pubJ^aUgn^sLorage and distribution center (FIG. 2). Each on . line Mps application on a customer's computer, 

customer workstation al so has a COS.so tjgt the customer Much of tfae power of the Mp m m residcs m {{s 

canjtoje^rKLretneve.ME-system objects when assembhng abiHty t0 my ^alt design and content, unlike existing 

conte^i^^ 0Q _ line and multimedia publishing tools which require a 

A tide may be broadly definedtc^enegmpass a publication 40 publisher or content provider, such as a first publisher 102, 

(e.g., newspaper), service (e.g., stock quotations) or appli- a ^ond publisher 104, or a publisher M 106 to integrate 

cation (e.g., multimedia encyclopedia). When a title is design and content. In the MP system, tides, such as a title 

viewed, the viewer opens a title file which represents the a 140, title B 142, or title P 144 can be divided into two 

title. This title file is a COS file. Typically in the on-line parts: the ( 148j 152j 156)— the information such as 

scenario, this would be a skeleton title. A skeleton tide is a 45 bitmaps, video clips, audio, animation, or stories that make 

COS file which contains only a root moniker and no actual U p a title—and the tide layout, also termed the design (146, 

objects. A moniker is an object used in the implemen tation 150, 154)— the overall look and feel of a title. To separate 

of Jhe_COS and contains identification and status informa- content and design using the MPS rather than placing 

lion about COS objects. content directly on a page, a publisher can place the content, 

AsuperCOS is a COS file which contains more than one 50 such as a set of content objects 112, 114, or 118, in one or 

subordinate COS, known as a subCOS. For example, a m0 re containers of a title and then create sections or sub- 

superCOS at the customer workstation is used to cache sections having pages with special controls, such as a set of 

objects which have been remotely retrieved from the host title layout objects 110 or 116, that dynamically find and 

data center. As long as these cached objects are not out of display the content at runtime. 

date_ pr flushed,J he^v iewer wUU y,abie_to quickly provide 55 Using this technique a publisher can change a title on an 

thaTobject the next time it is requested rather than retrieving ongoing basis by merely updating the content 112, 114, 116 

it from the data center again. This gives the MP system a which has been placed into various folders or containers 

tremendous speed advantage over other on-line systems. within the master title. When a page is displayed, it shows 

A top level system flow diagram is presented in conjunc- the updated content. This is called dynamic tide synthesis or 

lion with FIG. 5 and exemplary Vie wer screen displays that 60 dynamic synthesis, and allows content to be continually 

could be se en during the proce sses" o t the system flow updated without any need to modify and update the title 

diagranf are described in conjunction witfTFIGS. 6 and 7. An design consisting of the individual pages, controls and 

example of the rendering process and a query that are used hand-placed content used to display the content, 

to display the title to a customer are presented in conjunction When publishers use dynamic synthesis they are creating 

withJ^gSJL and 9. Fi nally, a top level software execut able 65 tides which contain placeholders that will be filled-in by the 

and(SP^L L)view..oltb£^svstem is presente d in coni unction changing content. When dynamic synthesis is utilized, a tide 

witr^FIfi.. 10. is used as a template and a pressing is the displayed, filled-in 
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title. Each time the publisher updates the content in a title 
and makes it available for customers (also known as end- 
users or client end-users), such as a first customer 160, a 
second customer 162 or a customer N 164, the publisher is 
creating a new release of that title. When the customer starts 5 
to view that release, a "pressing' 1 is made which contains 
part or all of the content in the release. 

A major advantage of this approach is flexibility. Some 
parts of a title may be created by hand-placing content 
directly on a page, and other parts may be created using to 
dynamic synthesis. Notice, however, that content hand- 
placed directly on pages is static — it changes only when the 
people involved in creating the title update the pages. 

Returning to the creation of title layouts and content by 
the publisher, after creation, the title layouts 110, 116 and 15 
content 112, 114, 118 are released and stored in a publication 
storage 120. The storage 120 can be implemented in many 
forms, such as a network 122, CD-ROM 124, and other 
means of storage, such as bulletin boards, magnetic media, 
cable television and so forth. 20 

The presently preferred network 122 is the Microsoft 
Network (MSN), which can be accessed, for example, by 
Microsoft Windows 95. Of^cojirse,.the_MBSJs.designed to 
be portable so that it can_be_used_on_any-on4ine network 
incluSng_tor J not limited to, Internet, America On -Line, 25 
Compuserve and Prodigy. 

In the presently preferred embodiment of the storage 122 
as the MSN, many customers will use a MSN Explorer tool 
to acquire and activ. ate_^MPS application s. 

The MSN Explorer is the integrated navigation tool 30 
within Windo ws 95 tha t is also used to browse the MSN 
hierarchy. Sophisticated customers may use other more 
advanced MES Lfeatures, such as search, scheduling, and 
automatic delivery, assuming these features have been acti- 

ated by the publisher. Besides browsing via the Explorer or^ 35 
scheduling automatic home delivery, there are several addi- 
tio nal ways customers can obtain MPS applications. Fo r 
example, <gn mdividuaT^ppucation may be distri buted via' 
floppy disk or Ci^RDM 124 T it mav be distributed thro ugh' 

E : niall Or bulle^n^Q^rds^uUhP, flppli'raH nn may he. (\\rec.t\v 40 
accessible yia a link in otfter a pphcationsZbai ch as the 
Micr osoft Network yellowjrages svstemV ln each of these 
situations, the MP system 100 acquires an application for th e' 
2u£iQffler. 

C. System Components 45 

Referring now to FIG. 2, the preferred basic components 
of the MP system 100 will now be described. The system 
100 includes a set of tools for designing, developing and 
viewing multimedia on-line applications. A publisher, such 
a s the publisher 102, utilizes a publisher workstation (also 50 
known as a computer or machine) 182 and a Designer 
software environment 194 to create and publish the title 
layouts HO and content 112. In the system 100, a publisher 
could possibly just create content and use the title layouts of 
another publisher. The title layouts and/or content are pref- 55 
erably stored in a network 122 that includes a high- 
performance server for hosting on-line applications. The 
preferred network 122 will be further described in conjunc- 
tion with FIG. 3. A customer, such as customer 162, utilizes 
a customer workstation 182 and a runtime Viewer softwa re 60 
component 202 tr> find and activate MPS tit1es 1 stored nn the 
n etwork 122, on a visual display at a workstat ion 182. 

The Designer 194 is an extensible design and develop- 
ment environment that includes several preferred software 
components. These include a project editor 184 to manage 65 
tiles, containers, and objects; a page editor 186 to create and 
layout pages; a style sheet editor 187 to edit style sheets; a 



search object editor 189 to create search objects; a word 
processor, such as a MPS Document Editor 188, for creating 
content optimized for the MP system 100; and optional 
third-party tools, such as a sound editor 190, an image editor 
192, and another media object editor 193 to create and 
modify sound, image, video, animation and other content 
objects. For authoring textual content, the preferred docu- 
ment editor is an enhanced version of the Microsoft 
Words®6.0 word processing program for creating tagged, 
hypertext documents. Together, these programs form the 
Designer Component 194. 

The project editor 184 is used to invoke a style sheet 
editor 187 that is used to create and edit style sheets. The 
style sheet editor 187, and portions of the project editor 184 
and page editor 186 will be described in detail in subsequent 
sections of this discussion. 

The MPS Designer 194 is a page or forms-based devel- 
opment system similar to Visual Basic. The development 
environment is graphical and easy to use. Controls, which 
represent the components of a MPS application that will 
appear on-screen, are laid out within MPS pages. MPS pages 
and controls are preferably based on Object Linking and 
Embedding 198 (in FIG. 2) (OLE), Microsoft's component 
software technology. OLE, which presently is at version 2, 
is further described in Inside OLE 2 and OLE 2, Program- 
mer's Reference, Volumes 1 and 2, all of which are pub- 
lished by Microsoft Press. In addition, the System Overview 
chapter of Class Library User's Guide for the MFC Class 
Library, Microsoft corp., 1993, provides further relevant 
information. However, other compound document architec- 
tures such as OpenDoc could be used as well. 

A major feature of OLE is interoperability, the basis for 
integration between applications. This integration brings 
with it the need to have multiple applications write infor- 
mation to the same file on the underlying file system. OLE 
defines a model called OLE Structured Storage for treating 
a single file system entity as a structured collection of two 
types of objects; storages and streams. These objects act like 
directories and files, respectively. 

The OLE Structured Storage model generally implements 
these objects; applications rarely, if ever, need to implement 
them. These objects, like all others in OLE, implement 
interfaces: IStream for stream objects, IStorage for storage 
objects. 

A stream object is the conceptual equivalent of a single 
disk file. Streams are the basic file system component in 
which data lives; each stream has access rights and a single 
seek pointer. Through its IStream interface, a stream can be 
told to read, write, seek, and perform a few other operations 
on its underlying data. Streams are named by using a text 
string; they can contain any internal structure because they 
are simply a flat stream of bytes. In addition, the functions 
in the IStream interface map nearly one-to-one with standard 
file-handle-based functions such as those in the ANSI C/C++ 
run-time library. 

A storage object is the conceptual equivalent of a direc- 
tory. Each storage, like a directory, can contain any number 
of substorages (subdirectories) and any number of streams 
(files). Furthermore, each storage has its own access rights. 
The IStorage interface describes the capabilities of a storage 
object, such as enumerate elements (dir), move, copy, 
rename, create, and destroy. A storage object itself cannot 
store application-defined data except that it implicitly stores 
the names of the elements (storages and streams) contained 
within it. 

The OLE Structured Storage technology solves problems 
associated with previous flat file systems through the extra 
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level of indirection of a file system within a file. With OLE, 
a particular application can create a structured hierarchy 
where the root file itself has many substorages. Each sub- 
storage can have substorages within it, and so on. 

This structure solves the problem of expanding informa- 5 
tion in one of the objects: The object itself expands the 
streams in its control, and the implementation of storage 
determines where to store all the information in the stream. 

The MP system 100 includes a number of pre-packaged 
controls such as navigation controls, rich -text controls, to 
multimedia controls, and other special controls specifically 
designed to support the creation of MPS applications. 
Because the MPS is based on OLE, third parties can also 
design their own controls for use within the MPS (using the 
Microsoft OLE Control Development Kit that is bundled 15 
with Microsoft Visual C++ 2.0). In this way, the MPS 
development environment is fully extensible so that custom- 
ers can add new capabilities to their MPS applications by 
purchasing additional controls from third parties or by 
creating their own controls. The MPS development envi- 
ronment also includes a Visual Basic for Applications 
(VBA) scripting and debugging system. 

While content is displayed within controls that have been 
laid out on MPS pages in the MPS Designer 194, content can 
be authored in any number of existing Microsoft and third- 
party tools. One such tool for authoring hypertext is the MPS 
Document Editor 188 that supports special MPS features for 
creating and tagging MPS text. Other existing tools for 
creating bitmaps, complex drawings, and other multimedia 



later activates the same title when the computer is attached 
to a larger display. The second activation will result in 
another pressing to take into account the much larger screen 
area, if the publisher has enabled such an option. When the 
title is activated, the MPS Viewer 202 determines if the title 
is out of date; acquires any needed, information; and then, if 
necessary, creates and possibly personalizes the pressing. 

The MPS Viewer 202 enables customers to perform the 
following actions within the limits defined by content pro- 
viders: select and personalize the information a title 
acquires, modify the overall structural properties of titles, 
personalize the look and feel of titles, manage and archive 
the content customers acquire, and view billing and pricing 
information. 

The requirement for the preferred publisher workstation 
180 is, a Windows 95 workstation with the minimum hard- 
ware configuration necessary to run the MSN sysop tools 
and to store and display the titles under development. The 
preferred Windows 95 workstation has, at a minimum, an 
Intel 486 processor running at 33 MHz or better with eight 
20 Megabytes of memory. A 9600 baud or faster modem is 
required to run the MSN sysop tools. For multimedia titles, 
this includes a MPC2 compliant (multimedia configured) 
workstation. / ^-~ e ==^ 

The MPS Viewe^202 sjjbuld be installed on the customer 
25 workstation 182 beTorean MP S title is activated. The 
presentljLpteJprred customer workstation is capable of run- 
nmgWindows95. To make this installation easy, the Viewer 
lUtomaticall y installed onto the customer works tation 



Sals 



182 the first rime .the customer-connects tn MSN and the MP 
content can be used to create the content displayed within 30 sy stem 100 is enabled. MPS titles may include resources 



any particular OLE Control. In addition, most existing OLE 
Controls (.ocx executable programs) will work in the MPS 
environment although they may not be optimized for on-line 
applications. For example, a standard AVI OLE Control 
could be placed in an MPS application. 

The controls that are part of the MP system 100 are 
optimized for low bandwidth on-line delivery of data. 
However, the use of high bandwidth data delivery is within 
the scope of the present invention. The MPS 100 is designed 



such a s fonts JDvna mic Link Libraries (DLLs), and OLE 
contro ls jhat are. rilaced into the resource container or folder 
of MPS titles. Before customers can view such titles, these 
resources are installed on their workstation 182. 
D. Network Storage 

Referring to FIG. 3, an exemplary network storage sub- 
system 122 will be described. FIG. 3 is a high level diagram 
illustrating the basic components of an on-line network 122 
in accordance with one embodiment of the invention. Mul- 



to operate with information that can change from minute to 40 tiple publisher workstations 102, 104, 106 and customer 

minute, daily, or monthly. So while the MPS can be used for workstations 160, 164 are connected to a host data center 

creating static titles that are hand-crafted and cannot be 242 by a wide area network (WAN) 240. The publisher 

easily updated on an ongoing basis, the main focus of the workstations preferably have high speed connections to the 

MP system 100 is to provide an efficient, cost-effective WAN 240. The wide area network 240 includes WAN lines 

mechanism to manage the creation and management of 45 244 which are provided by one or more telecommunications 

dynamic, continually changing on-line applications. At the providers, and which allow end users (i.e., publishers and 

same time, as an open development environment, many of customers) over a wide geographic area to access the host 

the tools commonly used for creating static multimedia data center 242 via modem. The WAN lines 244 preferably 

content can easily be incorporated into the MP system 100. include both X.25 lines and ISDN (Integrated Service Digj- 

When activated by the customer, the Viewer 202 exam- 50 tal Network) lines, 

ines the components of a selected title to see if any of the The host data center 242 comprises a plurality of appli- 

information required to display the pressed title needs to be cation servers 246 connected to a high speed local area 

acquired. It then acquires this information from publication network (LAN) 248 (which may include multiple LANs), 

storage 120 or local storage at customer workstation 182 and Each application server 246 has a unique server ID. As 

organizes it so that it can be displayed to the customer 162. 55 shown in FIG. 3, three of the servers 246 are MP System 



Thus a pressed title captures the set of information that is 
displayed to the customer at a given point in time. In other 
words, some titles might produce a new pressing every day, 
or more frequently, as the content changes. On the other 
hand, other titles may be static; when a static title is activated 
there is no need to do another pressing, since the content has 
not changed. 

While pressing a static title may seem unnecessary, the 
process of organizing and displaying the pressing can take 
into account customer preferences and display device char- 
acteristics. For example, suppose a customer activates a 
static title on a laptop when using the laptop screen and then 
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65 



servers (246a, 246b and 246c). Also connected to the LAN 
248 are multiple Gateway computers 250 also referred to as 
Gateways, which link incoming calls from end users to the 
application servers 246. 

It is envisioned that the host data center 242 may advan- 
tageously have on the order of one hundred Gateways 250, 
and between several hundred to several thousand application 
servers 246. A host data center of this type will be able to 
handle tens of thousands of simultaneous user logon ses- 
sions. 

As described below, the server side of each on-line service 
is preferably implemented using one of the following: (1) a 
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single application server 246, (2) a set of "replicated" Project C has two title folders 300 and 302 that could share 

application servers (i.e., application servers which run the a content folder 304; Project N-l has a title folder 306 and 

same service application or applications) that provide access a content folder 308; and Project N has a title folder 310 and 

to replicated (and locally-stored) copies of service "content" shares content folder 308 with Project N-l. Publisher 102, 

data (i.e., data provided to end user's of the service), or (3) 5 for example, could be a provider of raw statistics in content 

a set of replicated application servers that provide access to folder 292 but does not want t0 generate title layouts. The 

server-specific (non-replicated) service content data. publisher 102 may have an agreement with the publisher 104 

The host data center 104 also includes multiple Arbiter for the Polisher 104 to allow access and use of the content 

computers 252 that monitor, record and process certain types ^ ^S? 1 f° lder 292 ^ Polisher 106 has two projects 

of transactions to ensure consistency among replicated to * W a ™ 290 that ^ . lhe 0001601 f fol ? er ?°*> fo / f™ m ?l e ; 

application servers. The host data center 104 also includes du * l ? * e ?> mmoc \ s f*? ci matter of titles in title folders 306 

one or more custom Gateway computers 254 which link the and 3 J°" UluStrat ? d m F [ G * 4 > a P r ?'f?' such as the 

. - Aj( , . , . project 286, may contain multiple titles folders, 

host data center 104 to one or more external sera* pro- p Operational Description Including Top Level Flow Dia- 

viders 256, such as a credit card service that validates and g ra m 

executes credit card transactions. is Referring now to FIG. 5, a top level flow diagram of the 

The host data center 104 also includes a number of processes performed using the MP system 100 will now be 

administrative servers 258. The administrative servers 258 described. The flow diagram and this description introduce 

perform administrative functions such as accounting, the process 320 a publisher 102 or information content 

billing, network management, backup, system security, per- provider (ICP) would use to design and distribute MPS 

form an ce analysis, and server-to-service allocation. 20 titles. 

To route user service requests to the appropriate servers As previously stated, a title is a publication, application, 

246, the Gateways 250 must have some way of determining or service created using the MP system 100. For example, 

the unique IDs of the servers that are currently handling the the publication may be a monthly magazine, wherein each 

requested services. This is accomplished by means of a issue of the magazine is a new title. A title consolidates the 

service map (not shown), which contains information about 25 & x of instructions for assembling the information that is 

every service and server 246 in the host data center 242. displayed to the customer 160. Customers see tides as icons 

The service map is preferably generated by a service map on the Microsoft Network, on CD-ROMs, or in a file system, 

dispatcher 260, which may be implemented on a single Bv double-clicking (activating) on the title, name or icon, 

computer. me customer can interact with the title. 

In addition to generating a service map, the service map 30 1 - Peo P le aod Ta sks involved in Title Creation 

dispatcher 260 maintains a central repository of information The MP system 100 is designed to support large teams 

referred to as the "global registry" 262. The global registry creating complex on-line applications, as well as small 

262 contains various information about the present configu- teams creating individual works (and anywhere in between), 

ration of the host data center 242. For example, for each ^ section, however, discusses only the more complex, 

service group, the global registry 262 indicates the IDs of the 35 h ig n ' e nd operations. In simpler scenarios, one person could 

servers 246 of a service group, and the identity of the Arbiter perform more than one of the roles described below, and the 

computer 252 (if any) which is assigned to the service group. amount of materials (stories, artwork, advertisements, and 

Further disclosure of the preferred network 122 is pro- so 0D ) would be more limited than the materials described 

vided in a copending application also assigned to the nere - 

assignee of the present application, Microsoft Corporation, 40 n * process of creating and publishing a MPS title can be 

entitled "Architecture for LAN-Based On-Line Services broken in to a title -design phase and a release-creation phase. 

Network", U.S. Sen No. 08/503,307, filed on Jun. 7, 1995. T 06 P rocess is set up so that all of the content and layout that 

E. Container Hierarchy *s common across releases can be performed once in the 

Referring now to FIG. 4, the high level hierarchy of preparatory design phase, and then left alone. This aUows for 

containers for a plurality of publishers using the MP system 45 a smaller team and faster turnaround in producing each 

100 will be described. In the presently preferred release, 

embodiment, the MP system 100 utilizes a specific directory a - Title Desi gn 

structure with the MSN directory tree. This structure is The process of creating a new title begins with the editor, 

rooted at a specific folder (specified via the MSN global Assisted by business development staff, the editor decides 

registry 262) known as a container of publishers 280. Every 50 00 a tar S ct customer base, and on a concept for the title that 

publisher 102, 104, 106 will have at least one container or wiU a PP eal to that base - desi S n team then develops that 

folder called a project. For example, the publisher 102 has concept into a proposed organization for the contents of the 

a folder called Project A 282, the publisher 104 has two title - 

folders called Project B 284 and Project C 286, and the Before content can be put in place, a framework for the 

publisher 106 has two folders called Project N-l 288 and 55 title must be created. This involves: 

Project N 290. Content folders and/or titles are dropped into • Creating a section hierarchy within the title. 

the folder of the publisher. • Creating content folders to store stories, 

Allowing for multiple projects satisfies the needs of a advertisements, and other pieces of content, 

large publisher. For instance, a project could be assigned to • Creating search objects in each section of the title that 

one magazine (e.g., gardening) and another project could be 60 draw content from the appropriate content folders using 

assigned to another magazine (e.g., motorcycling). Thus, specified criteria. 

each month's issue could be archived as a title according to In some organizations, this work will be done by the 

volume and number in its respective project. editorial staff. In others, it may be done by the production 

As an example of how projects could be configured, staff. 

Project A 282 only has a content folder 292; Project B has 65 Once the basic framework is in place, the art department 

a title folder 294, and two content folders 296 and 298, along can create artwork to fill in the title's common elements, 

with a link to the content folder 292 of publisher A 102; This includes: 
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• A style sheet describing font usage and text layout. 
Page layouts for sections that dynamically gather their 
content. 

• Page layouts for sections that are always the same 
(cover, title pages, mastheads, and so on) 5 

• Logos. 

Optionally, organizations may want to include developers 
in the title design process. For example, the particular 
application being designed may benefit from the use of 
custom designed OLE Controls. These controls could be 10 
purchased, or developed in-house using the Microsoft Visual 
C++ development system. Additionally, the advanced fea- 
tures of the Blackbird system, including accessing the API 
or scripting controls to respond to events or automatically 
perform actions at runtime would require some development 15 
work, either in the high level scripting language (VBA), or 
in a lower-level language such as C++. 

b. Authoring and Title Release 

Once the framework is created, the staff can now turn their 
attention to creating individual releases. All of the work 20 
done in the conceptual phase above is potentially re -usable 
for every release. In fact, for a title with little need for 
detailed artwork, the rest of this process could merely be a 
matter of dropping edited content (including 
advertisements) into content folders. 25 

For dynamic titles, most (and potentially all) of the work 
is done within the Content Authoring environment. For 
static titles, it could all be done within the Title Design 
environment. In practice, most releases will involve some 
work in both of these environments. 30 

i) Writers Provide Tagged Content 

Content authors — including editors, writers, reporters, 
and forum managers — generate content, including struc- 
tured stories, using the content authoring environment. Writ- 
ers compose the textual content that appears in a title (or a 35 
release of a title). They hand their materials off to the 
editorial staff. The editorial staff is in charge of the overall 
content of the title. For multimedia titles, this role is very 
similar to the director of a motion picture or television 
program. 40 

The content authoring environment supports a variety of 
tools, such as, for example, a MPS document editor. The MP 
system 100 also supplies tools to specify and manage links 
and to specify story properties. Third-party tools may also be 
added to the content authoring environment. 45 

From a content author's perspective, creating structured 
stories can be as simple as typing them in the MPS document 
editor and applying certain styles. More sophisticated con- 
tent can be created though a variety of means, such as 
including links to graphics or placing special properties on 50 
a story. 

For content providers that do not want to expend much 
effort creating tagged content, the MP system 100 includes 
MPS document editor templates that handle most of the 
tagging for the author. 55 

ii) Editorial Staff Chooses Content 

Once the editorial staff has chosen the stories they wish to 
include in a release and are satisfied with the content of those 
stories, they pass them on to the art department to select and 
insert appropriate artwork, and to the production staff to 60 
place in content folders. 

iii) Art Department Supplies Specific Art 

The artistic staff is responsible for designing the more 
graphical aspects of the title. In the early conceptual phase, 
graphic artists work with the editor to design a distinctive 65 
look and layout. This includes font styles, colors, titles, 
logos, and page layout templates. The term "art department" 



is used in the broadest sense here. In the multimedia world, 
the role of an art department goes beyond traditional print- 
based artwork. 

The art department in many cases inserts the artwork into 
the stories and tags that artwork so that it will presented 
appropriately (placed inline in the story text, as a wrap, or as 
a pop-up). They then pass the stories on to the production 
staff to be placed in content folders. In the case of static 
titles, the art department designs new pages and gives them 
to the production staff to be placed in the title framework. 

iv) Advertising Department Supplies Copy 

The advertising sales staff sells advertising space in each 
release. The advertising sales department collects copy from 
advertisers who have bought space in the release, and 
delivers the copy to the production staff to be placed in 
content folders. 

v) Production Department Does "Paste-up", Proofing and 
Release 

The production staff does the fundamental tasks, such as 
paste-up, necessary to put a title or release together. Once the 
production staff has everything that goes into the release, 
they "paste up" the release by placing everything in its 
appropriate place and performing a "test-pressing" to make 
sure that nothing is missing. The editors, art staff, production 
staff, and advertising staff review the test-pressing to make 
sure that everything looks and works correctly. Once every- 
one is satisfied, the production staff places everything on the 
publisher's server and releases it to be copied to additional 
servers at the Microsoft Network data center. 

2. Top Level Flow 

The process 320 begins at a start state 322 and continues 
at a state 324 wherein the publisher 102 uses the MPS 
project editor 184 (FIG. 2) to create a project on their 
workstation 180. A project, such as project C 286 (FIG. 4) 
contains all the information needed to build and distribute 
one or more titles and any associated content. 

Moving to state 326, within the project, the publisher 102 
creates titles and content folders, such as title 300 and 
content folder 302 (FIG. 4). A title consists of nested 
sections that contain MPS objects such as pages or search 
objects. Folders typically contain MPS content objects such 
as stories or pictures. To make the process of managing 
titles, folders, and MPS objects easiuo understand and use, 
the preferred MPS project editoif l83^FIG. 2) looks and 
works like the Windows 95 Explorer. 

Proceeding to state 328, the publisher 102 uses the MPS 
project editor 184, page editor 186, style sheet editor 187, 
and search object editor 189 (FIG. 2) to create the MPS 
layout objects such as pages, styles, and search objects. The 
page editor 186 is also used to place controls (each control 
is a program responsible for handling a displayable region) 
on a page. 

Moving to state 330, the publisher 102 creates content 
objects using the MPS Document Editor 188, or the pub- 
lisher can use third-party tools, such as the sound editor 190 
or the image editor 192, that produce formats that the MP 
system 100 can interpret. The authoring and processing of 
content objects is further disclosed in a copending applica- 
tion also assigned to Microsoft Corporation, entitled "Struc- 
tured Documents in a Publishing System", U.S. Ser. No. 
08/503,307, filed concurrently herewith. 

The creation of content objects could also be done prior 
to any of states 324, 326, or 328. After the content objects 
are created at state 330, the publisher invokes the page editor 
186. If not previously done at state 328, the publisher lays 
out each page with at least one control. Selecting a control 
on a page lets the publisher bring up a context menu, of 
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which one item is a Properties selection. Choosing the 
Properties selection brings up a controFs property sheet. 
Among the property sheet pages are a story page and a 
picture page. The story page allows the publisher to choose 
a story content object that is to be displayed in a story 
control. The publisher could enter a path name to the desired 
content object. Alternatively, pressing a ". . ." button brings 
up a Content Browser dialog which allows for browsing 
within the project to find a desired story content object. The 
picture page is used for choosing a picture object to display 
in a control. The publisher could enter a path name to the 
desired content object. Alt ernatively, a Content Brow ser 
dia log allows the publisher to choose a picture con tent 
object fro m within the projec tTOther types of content objects 
are associated with a lay out object in a similar wa y. Further 
descriptions of the property sheet pages are provided below 
in conjunction with a discussion of controls. 

Proceeding to state 332, the publisher 102 releases the 
project. In the presently preferred embodiment, releasing a 
project makes the titles, stories, and other MPS objects 
available on the Microsoft Network 122. The MP system 
100 automatically connects to the network 122 and makes 
the titles in the project available to the customers 160, 162, 
and 164 (FIG. 1). Alternatively, the MP system 100 can 
release the title to CD-ROM 124 or other storage/ 
communications media. 

Continuing at state 334, the customer 160 uses the MPS 
Viewer 202 (FIG. 2) to read and page through (also termed 
navigation in an electronic publication) the released titles. 
As parts of the title are accessed, they are cached on the 
customer's computer 182 for fast access. The viewer 202 
organizes and composes the objects it has collected and 
displays them to the customer 160. 

Over time, the publisher 102 can update the project and 
the MP System automatically tracks the changes. Decision 
state 336 determines if the publisher desires to update the 
project. If the publisher does not wish to update the project, 
process 320 completes at end state 338. However, if decision 
state 336 is true, that is, the publisher desires to update the 
project, the process 320 moves to a decision state 340 to 
determine if the publisher 102 desires to modify the layout 
in the project. If so, the process 320 moves to state 342 
wherein the publisher modifies one or more existing layout 
objects or adds one or more new layout objects. If the 
decision state 340 evaluates to be false, or at the completion 
of state 342, the process 320 moves to state 344 wherein the 
publisher modifies or adds one or more content objects. At 
the completion of state 344, process 320 proceeds to state 
332 wherein the project is released again. Releasing the 
updated project ensures that the proper set of layout and 
content objects are made available to the customer 160 
(FIGS. 1 and 2). 

G. Exemplary Screen Display of Title 

Referring now to FIG. 6, an exemplary screen display 360 
of a page of a title as displayed by the Viewer 202 on the 
visual display at the customer workstation 182 (FIG. 2) will 
now be described. The screen display 360 corresponds to a 
World News section of a MSNLive title using a page layout 
which has been named NewsFront by the designer. A tabbed 
horizontal bar 362 near the top of the screen 360 is handled 
by a caption button control and shows the major sections of 
the title. By selecting a section name (by use of a pointer 
device like a mouse, not shown, but which is a part of or 
connected to the workstation 182), the customer 102 can 
navigate directly, through a link, to the selected section. 

Below the bar 362 of screen 360 are two headlines 370 
and 372 which are the result of an outline control that can be 
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used as links to corresponding stories on another screen of 
the title. Block 373 in this example contains an advertise- 
ment resulting from a picture control. Block 374 contains a 
graphic and text resulting from a picture button control that 

5 provides a link to a weather screen. Areas 380 and 384 
display headlines for corresponding abstracts 382 and 386, 
respectively, and are the result of an outline control. By 
selecting the headline 380 or 384, the customer can navigate 
to the body of the corresponding story on another page of the 

10 title. Areas 390 and 392 display picture objects correspond- 
ing to the headlines 380 and 384, respectively, and are the 
result of picture controls. 

The objects and placement of the objectsjss^he displayed 
page _360 are determined by the published 10a. Of course, 

IS other objects or placements of objects coukH>e utilized by 
the publisher 102. 

H. Exemplary Screen Display of Project Editor Window 

Referring now to FIG. 7, an exemplary screen display 400 
of the parts of the content and layout for the example title 

20 displayed in FIG. 6 will be described. The Project Editor 
window 400 is the main interface for the Designer 194 (FIG. 
2). The window 400 is intended to closely mimic the 
Microsoft Windows 95 Explorer. Using this window 400, 
the publisher can open, edit and save a project, as well as 

25 release the contents of that project to the MSN Data Center 
242 (FIG. 3). An approximately left one-third of screen 400 
is a display area 402, also known as a left pane, that shows 
the hierarchy of containers of one project for a publisher and 
allows the user to navigate through it. The left pane shows 

30 only containers (folders, titles, and sections). An approxi- 
mately right two-thirds of the window 400 is a right pane 
404 that shows the contents of a container selected in the 
area 402 by the user of the project editor 184 (FIG. 2). 
Referring to the left pane 402 of the window 400, the top 

35 level of the hierarchy of containers is the project "MSN- 
Live" 406. Just below the project is the title "MSNLive" 
408, which in this example has the same name as the project 
406. In another example, the project could have a plurality 
of titles, such as a January issue of a magazine "X", a 

40 February issue of magazine "X", and so forth. Below the 
title in the example hierarchy are two sections: "News" 410 
and "Sports" 414. Also at this level in the hierarchy is a 
content folder 418 labelled "Graphics", which holds the 
picture objects used by the project 406. Below the sections 

45 410 and 414 is a set of subsections 412 for the "News" 
section 410 and a set of subsections 416 for the "Sports" 
section 414. The "News" section container 410 has been 
selected by the user, which is evidenced by the highlighting 
of the section label "News" and the opened section icon to 

so the immediate left of the "News" label. 

Referring to the right pane 404, the layout objects and 
content objects directly contained within the selected con- 
tainer in the left pane 402 are shown, e.g., the objects of the 
"News" section container are displayed in this example. The 

55 left pane 404 uses standard Explorer views, as well as a 
special view built for the window 400, which sorts according 
to a user-defined order and allows the user to change the 
order by dragging and dropping each objects' icon. The 
objects are preferably grouped by type of object, such as, for 

60 example, subsection objects 412, page layouts 420 and 
content objects 422. The order of the pages and content 
objects is significant. The title maintains a sequence ordering 
of the sections, pages, and search objects, as this is important 
in determining how the title is displayed. Within a section, 

65 the pages have a sequence that determines the order in which 
they are used to press content and the order in which they are 
displayed when the user browses sequentially. In a static 
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section, pages are displayed in the order shown in the project this manner, the designer can choose to only display a 

editor window 400. portion of a linked story within a static story control by 

A dynamic section uses the dynamic story control (FIG. adjusting or sizing the control to only hold one paragraph, or 

8) to display stories within a section. The stories are sorted other desired portion, of the story content. Normally, a static 

according to rules specified on the section *s property sheet 5 story control will allow scrolling of a story so that ultimately 

and then are concatenated or linked together. The stories are the entire story will be displayed. 

then filled into the dynamic story controls on each page in Finally, a story object 466 is linked to the story control 

the section, in the order in which the pages are arranged in 442 so that it is rendered in the area identified by the static 

the section. If there are more stories than there are pages, the story control 442 on page 434. In this example, the entire 

last page is re-used repeatedly until all content has been 10 story object 466 is rendered onto page 434. 

pressed. For instance, in FIG. 7, the Backpage in pages 420 It is important to note that each of these story objects 

would be reused. makes reference to the style sheet 443 before being rendered 

Toolbar buttons and corresponding menu commands on the page 434. When story objects are authored, they are 

allow the publisher to quickly add new objects to the titles given formatting tags that represent specific styles. As the 

and folders within the project 406. Clicking a button will add 15 story objects are rendered, they reference the style sheet that 

a corresponding object to the container selected in the left is linked to the appropriate control to retrieve formatting 

pane 402. Only those objects that are allowed to be in the information. This formatting information includes properties 

selected container have their corresponding toolbar buttons of the paragraphs, fonts and embedded objects in the story 

id menu items enabled. that format the content as it was originally designed. Due to 

I. Example of Rendering Process 20 the separation of design and content in the MP system, the 

Referring now to FIG. 8, the interaction of page layouts, story objects themselves only have formatting tags, but do 

having controls, and objects at the Viewer 202 (FIG. 2) of not contain a description of the particular format that cor- 

the customer's workstation 182 to render pages will now be responds to each tag. The descriptions of those tags is found 

described. The Viewer 202 supports the display of informa- in the style sheet that is linked to the control into which the 

tion through windows. The placement, organization, and 25 story object becomes rendered. This process will be 

number of windows is under the control of the publisher explained in more detail below with respect to FIGS. 9-15. 

102. Viewer windows are Windows 95 frame windo ws. 2. The Business Section 

These windows are completely under the control ot me As also shown in FIG. 8, the business section 432 contains 

desig ner. The designer controls the Viewer 202 by creating a first page 444 and a second page 446. The page 444 has a 

aJitle . The title sets the size and standard elements (title bar, 30 single static story control 448, a single picture control 450, 

Min/Max buttons, caption, border, menu bar) of the various and a first dynamic story control 452. The second page 446 

windows displayed by the Viewer 202. has two dynamic story controls, 454 and 456. In addition, a 

The entire client area of a viewer window is used to style sheet X 457 and a style sheet Y 459 are referenced by 
display a series of pages. Each page contains a set of controls the different controls on pages 444 and 446. The pages in the 
that are used to display content, to navigate through the title, 35 business section 432 differ from the page 434 in the front 
and to gather information from the customer. In response to page section 430 because they rely on a search object 468 to 
customers actions or other events, the page that is displayed retrieve particular stories. On the page 434, the static con- 
may change during the c ourse of running^ the title. This trols were each linked to a particular story which was then 
behay jor is determined by the publisher 10277Oitle may displayed upon rendering. The search object 468 is affiliated 
hav ejnore than one window visiDie at any given time, and 40 with the dynamic story controls in the section 432. 
popup windows may be modal or modeless. Only one title As shown in this example, the static story control 448 and 
may beoTsplayed within a Viewer window at any given time. the picture control 450 on the page 444 reference or link to 

FIG. 8 presents a diagram of a front page section 430 and the story object 464 and the picture object 460, respectively, 

a business section 432 for a title, such as a newspaper. and display these objects as shown on the rendered page 

1. The Front Page Section 45 444. The story object 464 is thereby shared between differ- 

The front page section 430 contains a page 434 which has ent sections, pages and controls in the title. The entire story 

a picture control 436, and a set of static story controls: a first object 464 is displayed on the page 444, whereas only the 

story control 438, a second story control 440, and a third first paragraph was displayed on the page 434. By using a 

story control 442. Each static story control or picture control similar process, a designer can choose to display just the first 

is linked at publication time to just one object. Each of the 50 paragraph of a story on the first page of a title, but include 

controls on the page 434 references a style sheet 443 to the entire story on another page within the same title. As 

provide formatting instructions on how the content is to be shown in FIG. 8, the picture object 460 is also shared 

displayed. between the control 436 and the control 450. This sharing of 

As shown in FIG. 8, a picture object 460 is linked to the content between separate sections and pages is an important 

picture control 436, so that upon rendering, the picture 55 feature of the MP system 100. 

object 460 is displayed on the page 434 at a position 3. Dynamic Story Controls 

determined by the control 436. Similarly, a story object 462 The dynamic story control 452 uses the results of a query 

is linked to the static story control 438 and rendered into the performed by the title to retrieve stories matching search 

position of the control 438 on the page 434. criteria set by the publisher (as defined by the search object 

Note that since the control 438 is a static story control, any 60 468). The search object 468 locates story objects having 

area not used by the story object 462 in the area identified specific properties. In the example of FIG. 8, the search 

by the control will be blank. As shown, a story object 464 is object 468 returned many story objects 470, 472 and 474 

linked to the story control 440 80 that it is rendered in the corresponding to story objects 1 through N, respectively 

area identified by the static story is control 440 on the page (where Nx4 in this example). All of the retrieved story 

434. In this example, for instance, only the first paragraph of 65 objects are concatenated together by the dynamic story 

the story object 464 will be rendered on the page 434 due to controls and poured into the appropriate regions on the 

the size of the control 440 (as selected by the designer). In pages. The order that the stories become rendered into the 
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control regions starts with the first dynamic story control on 
the page in the section and continues to other dynamic story 
controls contained within the section. 

If enough pages to display all the located stories are not 
defined in the section, the last page used is repeated until all 5 
stories are rendered. Thus, the first located story 470 is 
poured into the area defined by the dynamic story control 
452. Since it does not completely fit in that area, the located 
story 470 continues across the page boundary onto page 446 
into the area defined by the dynamic story control 454. The 
located story object 472 then begins after the located story 
object 1 470 ends. The next located story object (located 
story object 3) begins after the story object. 472 ends, 
continuing into the next control 456 on page 446, as shown 
in this example. The last located story object 474 retrieved 
by the search object 468 in this example is then rendered into 15 
the dynamic story control 456 within page 446. 

As explained above, the dynamic story controls in the 
section 432 use the search object 468 to display the results 
of queries made for specific information. For example, the 
search object 468 may return content that contains the word 20 
"Microsoft". Each of the stories found by the search object 
468 will be displayed in the areas defined by the dynamic 
story controls in the format designated by the style sheet 457 
or the style sheet 459. 

For example, if the dynamic story control 454 is linked to 25 
the style sheet 457, then all of the stories displayed by the 
dynamic story control 454 will appear in the format desig- 
nated by the style sheet 457. However, the stories rendered 
by the dynamic story control 456, when this story control is 
linked to a different style sheet (for example, the style sheet 30 
459), would appear differently than the formatted display 
corresponding to the dynamic story control 454. In this 
example, if the controls 454 and 456 use different style 
sheets, the located story 3 would be displayed using two 
formats when the transition from the area defined by the 35 
control 454 to the control 456 was made. 
J. Style Sheet Overview 

Style sheets and the style objects they collect are created 
by the designer (i.e., the person at the publisher workstation 
180 shown in FIG. 2) using the Project Editor and the Style 40 
Sheet Editor. Once the style sheet has been created, it is 
stored in the cached object store (COS) along with the other 
objects in the project as described above in reference to FIG. 
2. The style sheet objects support OLE serialization and are 
therefore based on the Microsoft Foundation Class (MFC) 45 
Cobject class. These class definitions are publicly available 
from the assignee. 

As described at the beginning of the detailed description 
section, a different style sheet may be linked to each control 
region on a page. However, in all likelihood, style sheets will 50 
be shared among more than one control. As is known in the 
present software technology, a globally unique identifier 
(GUID) can be used in OLE object-oriented environments to 
identify an object with a unique string of characters. 
Normally, unique GUIDs are produced by concatenating the 55 
time, date and network card serial number of the computer 
at the time that the object is created. By using this method, 
it is virtually impossible for two objects to receive the same 
GUID. In the MP system 100, each control keeps a record 
of a GUID associated with its linked style sheet. This is how 60 
a particular control can reference its linked style sheet. More 
than one control can refer to the same GUID, and therefore 
share style sheets. When a control needs access to its 
associated style sheet, the control requests the style sheet 
from the title. If the style sheet has not already been loaded 65 
into volatile memory, the title object bandies loading it from 
the COS. 



K. Customer Query 

Referring now to FIG. 9, a query path from a "Find" 
dialog through title searches to the content database at the 
publication storage 120 will be described. The query com- 
ponents for both publishers 102 and end-user customers 160 
are defined as follows: a MPS Document Editor Summary 
Information dialog — for tagging content with keywords to 
aid in retrieval; a Search Object Editor — for title designers 
to create and modify search objects (also known as infor- 
mation magnets); and a Find dialog 510 — a customer inter- 
face for ad-hoc and saved searches. 

Content, such as stories 502, 504 and 506, is tagged using 
the MPS Document Editor's Summary Information dialog 
and is placed in the MPS content database in the publication 
storage 120. Search objects gather stories which match a 
particular criteria (as defined in the Search Object Editor) 
and "flow" them into the appointed sections of a title in the 
Viewer 202 (FIG. 2). The Search Object Editor is the query 
tool which designers use to retrieve and locate relevant 
stories within the title. The customer 160 uses the Find 
Dialog 510 within the MPS Viewer 202 to issue one or more 
queries 512 against all the stories in a particular title (i.e., 
those stories the title has retrieved using one or more search 
objects). 

The queries 512 issued by the customer 160 in the Find 
dialog 510 are joined with the criteria of the title's searches 
due to the search objects) and then the aggregate is queried 
against the content database in the publication storage 120. 
Result GUIDs 514 (representative of stories matching the 
queries and search objects) are transmitted back to the 
customer and appear in a results pane 516 of the Find dialog 
510. By combining the query 512 with the search object 
queries restricts the results to be within the title structure 
rather than from any arbitrary source in the content database. 
L. API/DLL View of System 

Referring now to FIG. 10, the major software components 
or modules used by the presently preferred implementation 
of the MP system 100 will be described. The modules are 
located at the publisher location 102 (also shown in FIGS. 
1 and 2), at the network storage location 122 and at the 
customer location 160. 

The modules at the publisher location 102 include a 
publisher executable 530, a set of publisher DLLs 532, a set 
of publisher OLE custom controls 534, a publisher COS 544 
with a client object broker service and client publisher 
interface 546, OLE 198 and MFC 562. 

The modules at the customer location 160 include a 
viewer executable 538, the set of common publisher DLLs 
532, the set of common publisher OLE custom controls 534, 
a viewer COS 548 with a client object broker service 550, 
OLE 198 and MFC 562. 

The modules at the storage location 122 include a server 
executable 536, and a server superCOS 540 with a server 
object broker service and server publisher interface 542. The 
publisher executable 530 (also known as BBDESIGN.EXE) 
is an application which provides a mechanism for generating 
a design-time view of a project. It is utilized in the creation 
of objects within a project, and for establishing the relation- 
ships between the objects of a project. 

The set of publisher DLLs 532 includes a forms DLL 
(FORMS3.DLL) that provides the implementation of the 
OLE Control Container class and supplies the data for the 
page object in a project. Also included is a view DLL 
(VIEWDLL.DLL) that provides a set of MPS Object defi- 
nitions and the viewer engine for synthesizing the run -time 
view of a title. The MPS Objects include: CProject, CTitle, 
CSection, CFolder, CContentFolder, CRootContentFolder, 
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CProxyTable, eContent, CFrame, CBForm, CVForm, sharing content among titles and of separation of design and 
CStyleSheet, and CMagnet. content will be more fully described. This section begins 
The set of publisher OLE custom controls 534 (also with a discussion of the presently preferred authoring sub- 
known as BBCTL.OCX) is a DLL which provides the code system used by the MP system 100. Then, a tide designer 
for implementing instances of the OLE custom controls 5 subsystem will be described, which includes the objects 
which are standard for the MP system 100. available to the title designer; the project, page, style sheet 
T,J^J!^ r cxecu ! ablc 53 * (also known as and object cditors used t0 creatc and revisc the 
BBVIEW.EXE) is an apphcahon which provides a mecha- , ^ and the used iQ define ^ u of a 
niS hT" £ nlT^t nin-time view of a title It uses the N {hQ architectural structures used b he tem t0 
publisher OLE custom controls 534 and the publisher DLLs . 4 . .. , % , . ' 
en ■ it 4L c t u • - t u 10 enable the creation, revision, and storage of design layouts 
532, especially the viewer engine for synthesizing the run- , i_ j « t_ • r 
time view of a title content will be described. Finally, the operation of the 

Each of the publisher 102, customer 160 and network desi S ner P rocess ™ d release P rocess ^ be bussed, 

storage 122 locations has a COS implemented by using a A Auth onng Subsystem 

DLL (COS.DLL). The COS DLL provides a persistent Content is separated from design in the MP system 100. 

storage mechanism for objects used by the MP system 100. 15 In ^ Viewer 202 (FIG. 2), content and design are brought 

The COS DLL uses OLE Storage technology to store sets of together by controls to display a title as specified by the 

objects in a compound document file. Each object placed designer. As a result, these controls need to identify different 

into a COS is given a unique identity, referred to as a GUID. elements in the structure of the content so they may format 

Each object identified by a GUID can be located indepen- it correctly. This is done by creating structured content. The 

dent of a path name in a file system. The server executable 20 MPS authoring environment provides a way for authors to 

536 (also known as MSNSERVER.EXE) is an application create structured documents. 

which provides a mechanism for managing the network The MPS authoring environment includes the MPS Docu- 

server, which includes the COS. In addition to the COS men t Editor 188, which supports the creation of structured 

DLL, the server has a DLL for COS access and object documents, insertion of links and the application of prop- 

^°&i^??y D ^ L) ' a MPS SeFVer service 25 erties to these documents for content retrieval. The MP 

Swni n } a mem0ry managCment b*™* system 100 uses SGML (Standard Generalized Markup 

(DhAKBbVDLL) Language) to define the scheme for creating structured 

Each of the publisher 102, customer 160 and network documentSi SGML is a standard for defining a markup 

storage 122 locations has an object broker service DLL , . - . , . . . , t ° , 4 ., 

(OBJBRK.DLL). Tne object broker service attempts to tangiiagp-^ set of tags and attnbu^used to identify the 

locate an object given its unique identity (GUID). By 30 S " T& ° f * M * ?J° ^f^^ Type 

default, the object broker first looks in its local object store Descriptor). The MPS Document Editor 188 will support 

(referred to as a superCOS), which is either the publisher savm 8 documents in a format which conforms to the MPS 

COS 544, the server COS 540 or the viewer COS 548. If the DTD (MPML— Multimedia Publishing Markup Language), 

object is not located at the COS wherein the request was ™s DTD ^ be published for use with other SGML 

made, and if the object broker resides on a client machine 35 authoring systems. As part of this environment, the MPS 

(either the publisher or customer workstation), it will provides a pair of Document Editor converters for reading/ 

attempt to remotely retrieve the object from the server COS writing MPML files, a template defining styles and macros 

540 at the MSN Data Center 242 (FIG. 3). In another used to f^atc MPML files along with some OLE controls 

embodiment, other object stores may register with a given used to insert and a Pply properties to these files, 

object broker as a source of objects, which the object broker 40 To create content for the MP system 100 in the MPS 

will search in between the local and remote retrieval cases. Document Editor 188, an author creates a document based 

Associated with the object broker 546 at the publisher is the on the MPS template. This template provides a set of 

client side of the publisher interface, and associated with the predefined styles along with supporting macros. The author 

object broker 542 at the network server is the server side of applies these styles to the text to identify the different 

the publisher interface. The publisher interface is used to 45 elements of the document (headline, abstract, body text, and 

manage the publication of new, deleted, and modified 50 forth). Only the predefined styles should be used. When 

objects. me document is saved in MPML format, these styles are 

The capabilities of the object broker allow a publisher to mapped to SGML tags by the MPML output converter. The 

test layouts or content that are shared with a different result is a ta g£ ed document which can later be parsed by the 

publisher. As an example, publisher A has a title layout A and 50 Viewer 202. 

publisher B has content that publisher B has agreed to share The MPML converters for the Document Editor 188 

with publisher A. To test title layout A together with the support mapping styles applied to the text to MPML tags. In 

content, publisher A could retrieve content provided by addition, it will support graphics inserted with the "Insert 

publisher B that is stored in the COS 540 by use of the object Picture" command of the Document Editor 188. This will 

broker service. 55 support both finked and embedded graphics and tag them 

AMPC Wrapper DLL (MWRAP.DLL) uses the Microsoft appropriately. The converters also provide support for the 

Network Procedure Call (MPQ protocol to communicate MPS °LE controls provided to insert links and apply 

with the network storage 122, i.e., the MSN Data Center 242 properties to the documents. 

in the presently preferred embodiment, and the MPS An important aspect of the authoring environment is that 

services, such as the object broker and COS. This wrapper 60 il ^ onl y to used to generate tagged content. The author 

specifically isolates the COS/Object Broker subsystem from should not expect that the style definitions made or format- 

the specific MPC protocol so that the MP system 100 can be UQ g applied in the Document Editor 188 will carry over to 

easily ported to use other protocols in other embodiments. me Viewer 202 when the document is displayed. 

As part of the authoring environment, several OLE con- 

IV. DESIGNER ENVIRONMENT 6S ^ m provided which i nter act with the MPS environment 

This section of the detailed description will describe the to help the author insert links and apply properties to 

designer environment at the publisher site. The concepts of documents. These controls are normal OLE objects which 



02/04/2004, EAST Version: 1.4.1 



US 6,199,082 Bl 



27 



28 



are extended to support rendering their data in MPML 
format. The MPML converters will be able to recognize 
OLE controls embedded in the Document Editor document 
and ask them for their MPML representation using a well- 
defined interface. When the converters encounter an OLE 5 
object, they will attempt to retrieve a MPML representation 
from them using this interface and insert it into the output 
MPML stream. OLE controls which do not support this 
interface will be ignored. The use of the interface allows 
extending the authoring environment with new OLE con- 10 
trols as needed. 

1. Story Editor 

AMPS story editor, which is part of the MPS Document 
Editor 188, is the main tool designers and authors use to 
create MPS story objects. AMPS story object consist of a 15 
stream of text with embedded objects such as links or 
pictures. MPS stories can also be tagged with Find proper- 
ties so that the MPS Find system can easily and accurate 
locate stories. 

The main tasks involved in the creation and delivery of a 20 
story are: author the story; set structural properties for the 
story; optionally, place pictures into the story; optionally, 
create links to other stories, and set summary properties 
(including Find matching criteria) for the story. 

In addition to using the MPS Document Editor 188 to 25 
create stories, publishers can create MPS stories with other 
tools or with an automated process. For example, stock 
ticker stories probably will be created automatically. 

MPS stories are structured, which means that the elements 
that make up the story are logically identified. This is useful 30 
because the MP system 100 can take advantage of this 
logical description to help present the information to users. 
The Document Editor 188 makes this easy, wherein authors 
merely apply the Document Editor styles. This process may 
also be performed automatically using filtering software that 35 
is supplied by Microsoft or by third parties. 

The MP system 100 supports three main file formats. 
These are: (1) the MPS data file format, (2) MPML, and (3) 
the HyperText Markup Language or HTML. The MPS data 
file format is the native MPS story format. It is a standard 40 
OLE doc file with separate streams for text and the various 
objects contained within the text stream. The MPML format 
is available to make it easy to import and export MPS 
stories. A MPML file is an ordinary text file that conforms 
to SGML. Because this file format is a simple text file, it is 45 
easy for publishers to automate the process of creating 
MPML files. Most publishers will not need to use MPML 
because the MPS tools automate the process. The MPML file 
format is only important because it can be easily converted 
to other formats, which ensures an easy migration path for 50 
publishers. 

The MP system 100 can also import and export HTML 
text files. However, because HTML is fairly limited many 
advanced MPS features can not be represented in HTML. 
The HTML and the MPML converters are constructed as a 55 
separate program that enables publishers to make batch 
translations of files. 

Stories are usually linked to other appropriate content, 
and MPS Find properties are added to the story so the story 
can be found by the query subsystem. These steps can be 60 
performed using MPS or third-party authoring tools. If a 
publisher uses third-party tools to produce content, the 
results must conform to the MPS file formats to ensure that 
the Viewer 202 can interpret the content. 

2. Links 65 
MPS stories typically have links to other stories or other 

information. The MP system 100 supports these hyperlinks 



through a link editor. The link editor is integrated into the 
Document Editor 188 and is accessible from the toolbar 
buttons or from an Insert\Hyperlink menu. A content selec- 
tor is used to select the target of links and to select pictures 
to embed in MPS stories. 
3. Find Properties 

To help customers find stories that might be interesting, 
the MPS supports the specification of keyword or keyphrase 
matching criteria through the file summary information 
option. A standard File\Summary Info dialog of the MPS 
Document Editor 188 is used to tag a story with retrieval 
attributes for search to find. Each field may be individually 
searched by the search editor. The Find dialog may search 
the title field uniquely, but the rest of the fields (subject, 
author, keywords, comments) are searched as a whole when 
the 'Summary' box in the dialog is selected. 
B. Title Designer Subsystem 

1. Overview 

This section describes the MPS title design environment, 
with emphasis on the Project Editor tool 184 (FIG. 2). The 
Project Editor 184 is the tool that provides a view into a 
project, and allows the designer to edit the contents of that 
project. 

A Source is a collection of MPS story objects stored on 
the MSN 122. In the presently preferred embodiment, each 
content folder is a separate source. In another embodiment, 
a single source may contain multiple content folders. 

2. Objects 

The Title Designer may interact with an open and exten- 
sible set of objects that are placed within a project (either in 
a folder or in a title). Objects appear in the Title Designer 
just as documents appear in the Windows 95 Explorer: as 
icons in the right pane. Objects respond to clicks, double- 
clicks, right-clicks (which display a context menu), and 
drag-drop operations as means to manipulate them. 

Nearly all objects in the system have a property sheet. 
This is a standard-format dialog which allows for setting 
values associated with that object. It is accessed by selecting 
Properties . . . from the File menu, or from the context-menu 
of the object. A property sheet consists of one or more tabbed 
pages, which the user may flip through by clicking on the 
tabs. At the bottom of the page are three buttons: OK, 
Cancel, and Apply. OK saves any edits that were made and 
dismisses the dialog; Cancel discards any changes and 
dismisses the dialog. Apply saves any edits that were made, 
but does not dismiss the dialog. Switching between tabs does 
NOT save changes that were made to the previous page. 

a. Project 

A project is a collection of titles and content folders. Titles 
and content folders are collected so they can be edited 
simultaneously and then released in the preferred embodi- 
ment to a MPS server 246 (FIG. 3) together. 

A project object represents the entire contents of the 
project, and is the container of things that get released 
together. As such, it has properties representing where the 
project's contents are released to, and statistics about the 
release process. 

b. Title 

A title is a collection of pages and supporting objects 
organized into a hierarchy of sections. The title itself, as well 
as each section, acts like a folder in that it can be expanded 
to show its contents within the Title Designer. It is important 
to note, however, that the items within a title have a 
hierarchical structure that is defined by the designer and is 
essential to how the title is displayed. 

A title also has a Resources folder that contains any 
additional objects that need to be distributed with the title; 
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for example, fonts and OLE controls. A title may have a content. In a static section, the pages are presented to the 

price associated with it, which is set using the MSN sysop end-user in the order in which they appear in the section, 

tools. A dynamic section uses the Dynamic Story control to 

A title object is a container for sections and pages. A title display stories within a section. The stories are sorted 

may also contain supporting objects, including style sheets, 5 according to rules specified on the section's property sheet 

content objects, window objects, and resources that need to and then are concatenated or linked together. The stories are 

be installed. A title object has a context menu with common then filled into the dynamic story controls on each page in 

commands, and a property sheet for setting all of its detailed the section, in the order in which the pages are arranged in 

settings. the section. If there are more stories than there are pages, the 

When a new title is first created, it is populated with the last page is re-used repeatedly until all content has been 

following objects: a resources folder having a default style pressed. 

sheet and a default window, and a blank page (directly under When in "home delivery" mode, all of the stories are 

the title object), named "Front Page". pressed at once; otherwise the system presses pages on 

A tide object contains pages and search objects organized demand. In the "on demand" mode, if the user chooses to 

into sections and subsections, as well as a collection of jump to a story out-of-sequence, the MP system 100 must 

supporting objects (style sheets, fonts, OLE controls, and so « choose a particular page in the sequence to start displaying 

forth). Pages and search objects may be contained directly mat st Because me Mp tem m has £J a * 

underneath the title, or they may be organized into a 0 portuni , t0 M of the stories tefore me one that ^ 

sequence of sections. W.ndows and style sheets are j ^ ^ ^ wW fa w fe ^ if 

placement-independent; they may also be stored within ' r ... . . . X. *. . , 

sections, or they may be kept in generic folders within the 20 use , rre * d the st ° ns ! s •» J^™- The des.gner may mark a 
tide. Fonts and OLE controls must be kept in the resources Pj^cular page to be the out-of-sequence page, which is 
folder. The title maintains a sequence ordering of the then used for these cases. Search objects are acUvated ni the 
sections, pages, and search objects, as this is important in ^ ucn f "> wh ' ch **l «PP«r w a section. Because of this, 
determining how the title is displayed. The views supported ordenn S ° f ob ] ects 10 • 5601100 has a subtle 
by the project designer window allow the publisher to 25 mflue fi nC ,f ° n * e final 0lde ™2 of ^^nts The sorting 
re-order these objects. speafied by me 5601,011 15 done as a stable 5011 ■ For 
The tide object is the section which represents the entire exam P le .: ,f ™° S athered by dMBwent search objects, 
title. From this root section the hierarchy of sections, search f 0 ?! 0 ' • S T ph< *' the °° e , wb °j* object was 
objects, pages and style sheets are added. The title object ^ first in the ? ct,0Q Wl " be hsted first " _ 
inherits from the section object and as such, it contains all 30 . ^ ^ eacc ° f .P a 8 es and lhe x <V* n< * oEsearch ob J ects 
the properties and attributes of sections. havc °° re ' atl0nshl P «° each other. They may appear inter- 
com a COS perspective, the tide object is the root object lea I? d m ' he con,ame ' u wi ! h no ™ us ™ 1 effects - , 
in an object store. The title has a reference to all first level . , Th ? secU , on ° b J ec < *e hierarchical structure of a 
sections, that is, it is the root section. htIe : h can be to 8 h ' o£ 35 a folder whlch can contaln other 
Like all COS objects, a smart pointer (CTitleSPtr) object 35 l * c t*** ( sub ^ ectl J 0 ^- ob J ec * st y le sneets ' P 4 ^' 
is defined to access the methods of a CTitle object. The f nd ^ different objects are managed m separate 
CTide object (like other COS objects) does not have knowl- ^sts bec4l f s °/ ^ ,bere are ^"but ***** API s 
edge of the COS which contains it. This information is kept f access each . of the . object types. There ,s no single 
in the smart pointer and all access should be through a homo g eDeous h* containing aU the objects that are part of 

CTiUeSPtr object. 40 a s ? cU , on - .. , . , . . . ... . „ 

C Section Sections provide logical breaks in a publication. For 

like the title object, a section object behaves much like a exam P^ the differe ° t P arts of ^newspaper can be repre- 

folder. It, along with its contents, can be dragged and f °^d by sechons: Front page, Sports Lifestyles, and so 

dropped. The only visible difference is that its contents has f ° r f h - Scctl0ns ako P Ia * a ? f P °!ii nt ^ com P oslD S 

a sequence that can be user-defined. 45 and navi S atlon features of tbe MPS 35 ^ow. 

Sections having Dynamic story controls may set whether 0 Dvnamic navigation to sections via information maps 

the Viewer 202 begins each story on a new page, or runs the ") ^ eci navigation to sections via action controls 

stories together. For sections having static story controls, iu ) Th e fr st storv of tne section is always composed on 

this setting is disabled. the first page of a section. 

The content gathered into a section is sorted at pressing 50 iv) Pages from previous sections do not propagate to 

time before it is displayed. The designer may specify the sort subsequent sections. Each section contains the pages 

order that will be used at that time. Available sort orders which are to be used to compose it's stories, 

include: Priority, wherein the author or editor may tag each v) The search objects contained in the section define the 

piece of content with a priority, (a number from 1 to 5, where content that will be displayed there, 

priority 1 is the highest priority), and Date/Time. 55 Ordering of objects in a section is important. The title is 

The designer may choose a specific page to use when the composed top to bottom, with sections at the top being 

viewer jumps to a story out of sequence. This allows the composed before sections further down. Similarly, pages are 

system 100 to quickly compose the story without needing to used in the order they appear in the section, and dynamic 

compose all pages in between the current position and the stories appear in the order of the search objects in a section, 

desired story. Without the ability to do this, navigating to 60 A smart pointer (CSectionSPtr) object is defined to access 

specific stories within a section would be painfully slow. the methods of a CSection object. The CSectionSPtr will 

The sequence of pages and search objects in a section help instantiate the CSection object from the COS and through 

to determine how the section will be pressed. However, the it's overloaded arrow operator, allow access to the section 

rules are different for static and dynamic sections, as methods, 

described below. 65 d. Window 

A static section has all of its content hand-placed on A window is a place a page can be displayed. A window 

pages. It does not use dynamic story controls to display may have a fixed size, or the height and width may be 
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changed at runtime to match the page being displayed in the section, then only one instance of that story is actually 

window. A window object may reside within a section in a collected and displayed in outline controls and in the 

title, or it may be contained within the generic resource dynamic story controls, 

folder in the title. The designer makes the decision about g. Style Sheet 

where the window object is to be contained. 5 The style sheet object encapsulates a mapping of style- 
The window object acts as an OLE frame object and client names to formatting instructions. The style names are a fixed 
site for an embedded page. The page object (or any com- set that authors can apply to their stories. In this way, authors 
pound document server) and the window object interact do not need to concern themselves with formatting their 
solely through the OLE Compound Document interfaces. content; they simply use a standard set of styles, and the 
The window object and page object together provide a full 10 formatting is automatically applied at pressing (using the 
in -place capable OLE container. The window object imple- style sheet that was designed into the title). Since outline, 
ments the IOlelnPlaceUIWindow for its document and the static story, and dynamic story controls rely on separate 
IOlelnPlaceFrame interfaces for its frame. It provides the content, they use style sheets as the basis for their format- 
object window (in the Windows sense of the word ting. 

"window*') and it also provides menu bar handling. 15 Opening a Style Sheet shows a list of the styles available. 

By breaking up an OLE in-place container into two parts The publisher may select a style and edit its properties by 

(window object and page object) using pressing the Modify . . . button. This displays a tabbed 

IOlelnPlaceUIWindow: :SetActiveObject, the page object property sheet that lists all of the formatting settings, 

can be attached and detached from a given window object at There are three types of styles: character, paragraph and 

run-time. This approach saves time by not having to destroy 20 wrap. Character styles may be applied to a selected set of 

and re-create a Windows window every time a new page is characters. They include only those settings that can be 

needed to display data. This is useful within the MP system applied to an arbitrary set. Paragraph styles (displayed in 

100 because it is very common to use two pages (e.g., bold in the list) are applied to the entire paragraph. They 

SectionFront and SectionDetail) to display a particular por- include extra settings that affect how the entire paragraph is 

tion of content. 25 laid out. Wrap styles (displayed in italics) classify wraps as 

e. Page to their functional use, so that they can be fitted to a 
A page is the representation of the layout of the client area particular area of the outline, static story, or dynamic story 

of a window. The layout within that page is represented by control. 

control objects. A page is a container for controls. In the h. Extensibility 

presently preferred embodiment, a Component Forms devel- 30 The designer may extend the design environment by 

opment environment for pages operates like Microsoft adding new OLE controls. These controls may support a 

Visual Basic or Microsoft Publisher in that designers place wide range of functionality. They may provide generic 

objects (controls) on a page by selecting and placing them. display capabilities (e.g. video, audio, sprites), or they may 

When opened, a page presents itself in "design mode" in utilize the MPS Information Map interfaces to provide new 

which the user can lay out the page with controls. Properties 35 means of navigation. OLE controls may also add additional 

of the objects are available through property browsers or a actions to a list of available actions, 

context menu. i. Content Folder 

Pages are contained within sections. Within a section, the A content folder is a container of story objects. It may 

pages have a sequence that determines the order in which contain story objects, and other folders. When a project is 

they are used to press content and the order in which they are 40 released, the contents of each content folder in that project 

displayed when the user browses sequentially. are copied to their respective source on MSN 122. Search 

A page may be used in more than one section; this is objects are set to look for content within a specific source, 

accomplished by making a shortcut to the page in another Through the Project window, the publisher may place stories 

section. A shortcut to a page has a place in the sequence of within these content folders so the search objects can find 

pages just as the real page does. 45 them when the stories are released to the source on MSN 

A page object is an implementation of an OLE compound 122. 

document server. The page object can contain any arbitrary Content folders are containers for titles and for story 

OLE control to create any type of Windows application. The objects. They appear as top-level items underneath the 

page object supports OLE controls fully and is a full Project, and may have further sub-folders. Search objects 

compound document server that also supports in-place acti- 50 use Content Folders to identify the scope of their query, 

vation with the lOleClientSite, IOlelnPlaceSite, and IAd- Content objects are represented by a generic document 

viseSink interfaces on its site objects. Unlike most OLE object within the designer. There are two kinds of content 

implementations, the page object requires a window object objects: Stories and Pictures. Stories represent MPS stories 

to become an OLE container. The window object wraps a while pictures represent wavelet or metafile pictures. When 

page object and displays it in a top-level window or child 55 the New Content command is used to load in a new picture, 

window. To work properly with controls, the page object the picture is automatically converted to a wavelet, unless it 

also implements an IDispatch interface for ambient proper- is a Windows metafile (in which case it is left unconverted), 

ties and an IDispatch interface for control events on its sites, Pictures which are saved as wavelets also have a property 

along with a new IControlSite interface that serves as a page which allows for controlling the amount of compres- 

notification sink for changes in a control's mnemonics. 60 sion that is done on the image prior to sending it to the 

f. Search viewer for display. 

Search objects describe how to collect stories to be Objects may be drag-dropped from the desktop or the file 

pressed into a dynamic story control. Only sections with system into a content folder. These objects will then be 

pages having dynamic story controls take advantage of released to the Data Center 242 when the Release command 

search objects. A section with one or more dynamic story 65 is selected. When objects are brought into the system 100, 

controls may have zero or more search objects collecting the project stores a path to the original file that was copied 

stories. If two search objects collect the same story into a in. 
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J. Resource Folder 

Titles may need additional resources, such as fonts and 
OLE controls. The designer adds these items into a project 
by drag-dropping (or copy-and-pasting) them into a title. 
Each title has a Resources folder directly underneath the title 
object, with sub folders named Fonts and Controls. The 
designer adds new items to the title by dropping them into 
those subfolders. 

The designer may also place window and style sheet 
objects within those folders, which are not necessarily 
associated with any particular section. This allows for man- 
aging the supporting resources separately, or for keeping 
them with the sections that use them. 

The MP system 100 assumes that all of the OLE controls 
and fonts in the Resources folder need to be installed on the 
customer workstation 182 to run the title. 

k. Shortcuts 

Just as in the Windows 95 Explorer interface, shortcut 
objects may be created and used through the project in place 
of the objects to which they refer. For instance, if the 
designer wished to use the same page in five different 
sections, then the designer can create the page in one 
location and place shortcuts to that page in the other four 
locations. Since none of the object's properties are 
duplicated, changing the original will change its use in all 
the places where shortcuts to it exist. Shortcuts are 
sequenced exactly as their referenced objects would be 
sequenced. For example, a section can contain a mixture of 
pages and shortcuts to pages, and the two could have a 
single, potentially intermixed, sequence. The "Go to specific 
page" action takes as a parameter any page or shortcut to a 
page. Shortcuts must point within a title or content folder. 
Shortcuts may not point between titles or content folders. 

3. Project Editor 

The Project Editor 184 provides the user environment and 
editing facilities for creating and editing MPS projects and 
titles. The Project Editor 184 limits itself to defining the 
structure and organization of the title, leaving the page 
layout and content definition to other parts of the MP system 
100. 

The publisher interacts with objects in the title through the 
Explorer-like UI provided by the project editor. The left pane 
of the editor contains the title structure elements (e.g., 
sections) and the right pane contains the objects contained in 
that section (e.g., search objects, pages, and so forth). 
Through the project editor, the publisher adds the sections, 
search objects, style sheets and pages which define the 
structure of a title. The project editor uses a drag-drop 
metaphor for moving and copying objects within, and 
between, titles. 

The project editor is the central editing point in design 
mode, and as such it interacts with the search object, 
stylesheet, and page editors to configure and set properties 
on the title objects. In most instances these editors are 
invoked by double clicking on an object in the project 
window. The project editor also supports the idea of styles 
where the properties of an object, say of a search object or 
section, are based on an existing search object or section. 

i) Interfaces 

The project editor provides two types of interfaces: 1) 
standard MFC C++ interfaces to integrate into the 
framework, and 2) an ITitleEditor interface to support the 
command architecture. Specifically, this interface is used to 
add, remove and modify objects in the project editor. 
Typically, these are invoked through menus or other UI 
components, but they could also be called via automation. 

The following services are required from other sub- 
systems: 
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Search Object Editor — the ability to invoke the search 
object editor to edit the properties of a search object; 

Designer/Forms 3 — the ability to launch the designer to 
modify a page; 

COS — all services are required; directly adds or queries 
the COS for objects through smart pointers; a smart 
pointer is a class wrapper which uses an IObjectStore 
COM interface to make programmatic use of the COS 
transparent; the COM interface can be used directly; 
5 Style Sheet Editor — the ability to edit the properties of a 
style sheet by invoking the style sheet editor on a 
selected style sheet object. 

ii) New Object 

A "New" menu command in the Project Editor 184 
' cascades to show a choice of objects that may be created in 

a selected container. Table 1 lists the items (in order) that 
. appear on the New menu when an object is selected in the 

left -pane: 
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TABLE 1 


SELECTED OBJECT 


NEW MENU CONTAINS 


Project 


Title, Content Folder 


Title 


Folder, Section, Window, Page, 




Search Object, Content, Style Sheet 


Section 


Section, Window, Page, Search 




Object, Content, Style Sheet 


Content Folder 


Folder, Content 


Folder (in a Title) 


Folder, Window, Page, Content, 




Style Sheet 


Folder (in a Content 


Folder, Content, 


Folder) 



4. Page Editor 

When a page object is selected in the Project window and 
35 the Open command is selected (or the page is double- 
clicked), the page is opened into a Page Editor window for 
editing. 

The Page Editor is the tool for creating and editing 
detailed page layouts. The client region of the window 
40 represents the page itself, and the rest of the editor window 
provides tools for laying out controls on that page. 

The key elements of the Page Editor are: 

i) A Menu Bar with commands for layout and editing 

ii) A Toolbar with shortcuts to common commands 

45 t 

iii) A floating palette Toolbox which allows for selecting 
controls to be dropped on the page 

iv) A grid which assists with exact placement of items, 
and Snap-to behavior which automatically aligns con- 

50 trols with the nearest grid point 

v) Undo/Redo support 

vi) Nudging support 

Double-clicking (i.e. opening) a page object brings up the 

Page Editor window, snowing the layout of that page. 
55 Selecting Close from the File menu will close the Page 

Editor. If any changes have been made that were not yet 

saved, the user will be asked whether s/he wishes to save 

those changes before exiting. 
The client area of the Page Editor window shows the 
60 layout of the page. Each control on the page appears in its 

appropriate location. 
Clicking on a control selects that control; the control then 

has a sizing border which can be used to resize the control. 

The control may also be dragged to another location by 
65 clicking in the center area of the control (i.e. anywhere 

within the sizing border). Right -clicking on the control 

brings up a context menu. 
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The File— »New command cascades to show a list of the 
available controls. Selecting a control from the cascade 
menu places an instance of that control on the page in the 
upper-left quadrant, with height and width one -quarter the 
height and width of the page, and with the top-left corner at 
a position one-quarter width and height from the top-left 
corner of the page. 

The Toolbox is a floating window which has a button for 
each of the controls available to the user to place on the 
page. This includes all of the standard controls, plus any 
additional controls that have been dropped into the title. The 
currently -selected control is depressed, and only one button 
is depressed at any given time. The toolbox also has an 
"Arrow" button, which is depressed when no control has 
been selected and indicates that the cursor can be used to 
select and reposition controls on the page. 

The user adds a control to a page by pressing on the 
control's button, then dragging the rectangular region on the 
page where the control is to be placed. The control is created 
when the mouse-button is lifted at the end of the drag. 

5. Style Sheet Editor 

The use of style sheets in MPS controls provides a way for 
the designer to set text formatting properties on a per control 
basis by creating and assigning a different style sheet for 
each control or a set of controls. Style sheets are created 
using the Style Sheet Editor 187 (FIG. 2) provided with the 
Project Editor 184. The Style Sheet Editor 187 allows the 
designer to customize style property values to override the 
default definitions for styles provided with each title. 

The designer uses the Project Editor 184 to insert/create 
a new style sheet in the Title. Initially, the style sheet is 
empty and simply uses the style definitions in the default 
style sheet. The designer can then invoke the is Style Sheet 
Editor 187 to define properties for the style sheet and change 
style property values. The set of styles supported by style 
sheets is predetermined. The designer cannot create new 
styles but can only modify the default property values for 
existing styles. 

When invoked, the Style Sheet Editor 187 displays a 
dialog listing the (predefined) style names and fields for 
editing their property values. These are retrieved from the 
default style sheet created by the title. Initially, these fields 
contain the default values defined in the default style sheet. 
The designer selects the style name of the style to customize 
and sets the desired new property values. When the prop- 
erties are set as desired, the designer causes the Style Sheet 
Editor 187 to create a new style object with the new property 
values and add it to the style sheet. The new style object now 
serves to override the default. The designer continues defin- 
ing new styles in this manner, as desired. When complete, 
the designer dismisses the Style Sheet Editor 187 and can 
proceed to assigning the new style sheet to MPS text 
controls. 

6. Search Object (Magnet) Editor 

The Search Object Editor 189 (FIG. 2) is a modified 
version of the customer Find Dialog 510 (FIG. 9). Since the 
Search Object Editor 189 is to be used by designers for title 
construction, there are a few differences: 

The Search Object Editor 189 is a modal dialog that 
behaves as the property sheet of a Search Object in the 
title designer. In the presently preferred embodiment, 
the Search Object Editor does not allow the designer to 
"Find Now" and test the query. After the criteria has 
been entered, the dialog is either committed with OK or 
dismissed with Cancel. In another embodiment of the 
system 100, the designer can select "Find Now" and 
test the query. 
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The In: checkboxes directly mirror the fields of the MPS 
Document Editor Summary Info dialog to give the 
designer more precise control than the customer when 
retrieving stories. 

In comparison to the Look In: field that appears in the 
Find Dialog and denotes what finished title(s) to search, 
the Source: field specifies the repository of stories to 
search for stories to be flowed into a title. These sources 
are accessed via the More . . . option at the bottom of 
the dropdown that launches a tree view of all content 
sources on the MSN 122. These sources are only visible 
to title designers and do not appear to the general MSN 
public. 

The search may be limited to retrieve no more than a 
certain number of stories to prevent a section from 
running too long. The designer simply specifies a 
maximum number in a provided spin control. 

7. Controls 

This section specifies only the preferred base controls 
i ncluded with the MP system 100. Oth er emfrofljrrmritS tfthe. 
syst em include controls for animation^ database^access. 
ele ctronic com merce..a nd,so_fort h. The following is a list of 
MPS specific controls included in the base MP system 100: 
Caption, Caption button, Pic ture^ Pi cture button, Outline,- 
(Static) Story, Dynamic story, ^nortou) , and Audio. Each of 
these controls is further described below. 

a. Characteristics 

A property sheet having pages is associated with each 
control. Most of the property sheet pages are used in more 
than one control. Note that no control has all of the property 
sheet pages; each control only has a small subset of the 
pages on its property sheet. Pages which are not applicable 
to a control do not appear as tabs on that control's property 
sheet. The property sheet pages utilized by the MP system 
100 include: 

• General — The General page lists general properties 
related to size and position. 

• Border Page — The Border page allows for setting the 
style and color of the rectangular frame around the 
control. 

• Action Page — (described below) 

• Text Page — The Text page allows for setting the values 
associated with displaying a text value. 

• Appearance Page — The Appearance page is used for 
setting text-display properties for richer displays than a 
simple caption (e.g., the story control). 

• Story page — The Story page allows the designer to 
choose the story object that is displayed in a story 
control. 

• Where to Look Page — The Where to Look page is used 
by information maps to decide which part of the title 
should be used to display information. 

• Bevel Page — The Bevel page is used for setting the 
bevel attributes of "button" action controls. 

• Picture Page — The Picture page is used for choosing a 
single picture object to display in a control. 

• Pictures Page — The Pictures page allows the user to set 
more than one picture, for example a button control 
which needs both an up and down picture. 

Both pictures must use the same placement, rendering, 
background and transparency settings. 

• What to Show Page — The What to Show page is used 
by the Table of Contents control to choose specific 
attributes of content to display. 

• Font Page — The Font page allows for choosing a font 
and style for those controls that have a single, consis- 
tent font throughout the control. 
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• Shortcut Page — The Shortcut page is used for defining 
a shortcut to a story or an MSN object. 

Color Page — The Color page allows for setting all of 
the color properties for each control. 

• Audio Page — This page is used by the Audio control 
for setting audio playback functionality. 

i) Action Property Page 

The Action property page is now further described. Con- 
trols such as caption buttons or picture buttons enable 
customers to invoke actions. A list of actions, provided in 
Table 2, is extensible by adding new controls which export 
additional commands. The action property page enables 
designers to associated these actions with events that can 
occur on the control. For example, in response to a mouse 
down event, the designer can associate the action to go 
forward one page. The standard actions include: 

TABLE 2 



Action 


Description 


Parameters 


OpenTitlcDlg 


Brings up Open Title dialog 




SaveAsDlg 


Brings up Save As dialog 




UpdatcNow 


Causes immediate update of title 




PageSetupDlg 


Bring up Page Setup dialog 




PrintDlg 


Brings up Print dialog 




Exit 


Quits the title 




EditCopy 


Copies selection to clipboard 




Go Back 


Jumps back to last page accessed 




AddSbortcut 


Adds a new shortcut 




ShowShortcuts 


Brings up the Shortcuts folder 




Find Dig 


Brings up Find dialog 




PrevPage 


Jumps to previous page in 
section 




NextPage 


Jumps to next page in section 




FirstPage 


Jumps to first page in title 




History Dig 


Brings up History dialog 




InterestsDlg 


Brings up Interests dialog 




Schedule Dig 


Brings up Schedule dialog 




PrefcrcnccsDlg 


Brings up Preferences dialog 




GoToPage 


Jumps to specific page 


page to 
jump to 


PrcvSection 


Jumps to first page in previous 
section 




NextSection 


Jumps to first page in next 
section 




GoToSection 


Jumps to first page in specific 


section to 




section 


jump to 


Run 


Runs a program or opens a file 


file to run 


CloseFrame 


Closes the current frame 





b. Caption 

The caption control is used to display simple textual 
information. The designer has control of the choice of text, 
colors, font, size and placement of the caption. The other 
major use of the caption control is to automatically display 
information about the title. For example, a caption control 
can be used to display the current section. This is useful if 
the page containing the caption is used in many different 
places. 

c. Caption Button 

The caption button control is closely related to the caption 
control. In addition to all the properties of the standard 
caption control, including the predefined automatic title 
information options, the caption button has an action page 
and bevel page. 

At run-time, the caption button displays a text caption 
within a button frame. Clicking on the button will cause a 
Click event to occur, which will then fire the associated 
action. 

At design time, the caption button displays itself as it 
would appear in its "up" position. When the control is 
selected, it has a sizing border. 
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d. (Static) Story 

The (static) story control automatically composes a layout 
for a stream of textual and graphical information. The layout 
describes the positions of text and graphics that are pre- 
sented within the area the story control covers on a form. 

The story control is closely related to the dynamic story 
control. The two major differences are: 

• The dynamic story control displays a sequence of 
stories found in a section of title, whereas the story 
control stores the information internally. 

• The story control can not display information in page 
mode. Dynamic story controls can display information 
that spans multiple pages. Note however, that the story 
control is scrollable, in which case this restriction is 
less important. 

i) Performance 

The preferred story control takes no more than two 
seconds to place text and graphics on a typical screen 
oriented publication. This is to ensure that the story control 
can provide layouts at rates comparable with 9600-caud 
modem communications speeds. In other words, a typical 
short text story — the size that would fill the first page of a 
typical publication — can be delivered to the customer's 
workstation 182 in approximately two seconds. This would 
mean that a 30 page publication could be "paginated" in 
under a minute. Note that the process of creating a layout 
may occur in the background, so customers may not expe- 
rience delays when navigating throughout a publication. 
Once the layout on a page is finished, the time required to 
repaint a page (excluding graphics) should be small, <250 
milliseconds, in order to compare favorably with paper- 
based publications. 

ii) Elements of a Layout 

The story control operates on three kinds of elements: 

• Tagged text. This is text with logical descriptors, such 
as headlines, that is styled and placed into a story 
control. 

• Inlines. An inline is a graphic that is associated with a 
particular point within the text. For layout purposes an 
inline is essentially treated as a character for layout 
purposes. 

• Wraps. A wrap is a graphic that may be placed 
somewhere within the control. While a wrap may be 
associated with a particular point in the text, it will not 
typically be placed at that point, but instead will "float" 
to an appropriate point within the presentation. 

iii) Types of Graphics 

The story control can support any OLE object or MPS 
custom control. For purposes of composition, the preferred 
story control treats all graphic as simple rectangles. In 
another embodiment, other shapes for the graphics are 
supported. In general, the story control does not know what 
is contained within a graphic. Consequently the story control 
considers objects that require interaction with the customer, 
such as shortcuts, to be simple graphics. The story control 
ensures graphics are drawn when appropriate and that cus- 
tomer generated events are delivered to graphic objects, such 
as links represented by a picture, that require the informa- 
tion. 

iv) Presentation Options 

The story control supports vertical, single-column scroll- 
ing. The story control does not support page mode, i.e., it 
does not display information that spans multiple pages. 

v) Story Control Properties 

Story controls have the following properties: number of 
columns, margins, a style sheet (the style sheet maps the 
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logical tagged source text into rendering information), and a interacts with the link manager to have the link updated 

source specification (determines the source of tagged text for (visually on the screen) after it has been resolved at least 

the story frame). once. This indicates to the user that the link has already been 

vi) Run-Time Mode resolved at least once and therefore the target of that link 
During run-time the story control provides distribution of 5 already exists locally in the COS. 

customer events to embedded MPS OLE controls, support The dynamic story control interfaces with the title man- 

for scrolling, and rendering of text and graphics. ager to convert style tags to style objects which can then be 

vii) Design Mode used to apply the appropriate formatting to the text. 
During design time, the story control provides the f- Picture 

designer with the ability to set properties and edit the content to The Picture control displays a bitmap or metafile. It can 

of the control. To edit the content of the control, the designer display the picture all at once, or it can progressively render 

must edit the story object that the control points to. The the picture. The Picture control does not embed the picture 

designer can access the properties of the control by selecting within the instance of the control, but rather, it points to a 

"Properties . . from the context menu of the control. separate Picture object within the title. 

e. Dynamic Story 15 The run -time mode displays the picture as configured in 

A dynamic story control is a story control that has its me Property Sheet at design-time, 

content dynamically gathered, rather than statically placed at The design-mode of the control is identical to the run -time 

design-time. Each page in a dynamic section may contain mode, except that when selected, the control has a sizing 

one or more dynamic story controls. When the title is border, and the user may set the picture by selecting the 

pressed, the content is gathered and flowed into the dynamic 20 control and (from the property sheet) browsing within the 

stories on the pages in that section, re-using the last page title to select a desired picture object, 

until all content has been pressed. g- Picture Button 

The run-time behavior of a dynamic story control is The picture button control provides the designer with an 

similar to that of a (static) story control except that when a up and down picture and animated button wrapper around 

dynamic story control does not scroll, the stream of data is 25 the two pictures. This control supports the following events: 

flowed into the next dynamic story control on the page or to click > right dick, mouse down and mouse up. 

the next page. The Run-time mode displays the "up" picture until the 

During design mode, the designer can set properties of a user clicks down on the control, at which point it then 

dynamic story control and can specify the order that the displays the "down" picture. The Design mode displays just 

dynamic story controls will display themselves on the page. 30 the "up* picture, with a sizing border when the control is 

Properties are accessed via the properties menu item on the selected, 

context menu. h. Outline 

The dynamic story control is the control that is used to The outline control is used to display information about 

format, layout, and display the story text of the results of a the title and the stories contained within the title. During 

search object on a given page. This control provides a fairly 35 run-time mode, this control displays sections (if chosen) and 

full set of text layout, formatting and display capabilities tags (those selected in the property sheet) and displays them 

including text insertion, deletion, replacing; character and according to the style sheet selected. Clicking on any item 

paragraph formatting; page setup; line layout; tabs; text navigate to that item in the title. During design mode, 

wrapping around intrusions (tight and rectangular wrap); this control shows sample displays for each of the types of 

in-line graphics; backgrounds; and creation and hit detection 40 content chosen in the property sheet, using the selected style 
of hot links. 

The dynamic story control also provides the capability for ( iJShortcut 

read-only type user interactions such as mouse-clicking, ^Ine Shortcut <x>ntrol_is used for defining a shortcut to.a 

mouse and keyboard selection, selecting and activating hot sperifj estory or a^M icrosoft Net work oj5re5t (title, chat or 

links, and copying to the clipboard during view mode. 45 BBSsession, and soforth). 

The main distinguishing characteristic of this control In run-time mode, the control is transparent, except for the 

vis-a-vis the (static) story control is that the contents of this standard shortcut icon in the bottom-left comer. When the 

control are gathered dynamically via search objects and mouse-cursor is over a shortcut control, the cursor changes 

inserted into the control programmatically rather than ere- to a hand; this is behavior is the same as for the button and 

ated statically at design time by the designer. When the 50 outline controls. 

designer creates one of these controls he/she will not author The design-time behavior is very similar to the run-time 

the contents of the text directly. That is, there is no editing behavior, except that when selected, the control has a sizing 

capability for this control in design mode. border that allows the control to be moved and resized. It 

i) Interfaces also has a standard context menu and property sheet. 

The dynamic story control interfaces with the Viewer, link 55 j - Audio ^ 

manager and title manager. The audio control allows for playing an audio object when 

The dynamic story control interacts with the Viewer 202 a page is active. In run-time mode, the control is transparent, 

to accomplish page setup and composition. The dynamic The design- time behavior is very similar to the run -time 

story control gets a parse tree node from the Viewer 202 behavior, except that when selected, the control has a sizing 

where composition should begin. After composing, it will 60 border that allows the control to be moved and resized, and 

notify the Viewer of the last character that was consumed the word "Audio" is repeated throughout the control region, 

during the composition. Also, when a link is clicked on it It also has a standard context menu and property sheet, 

will pass the link to the link manager for link resolution (i.e. The Audio control adds the following actions to the list 

to traverse the link and move the user to the target of that available to button controls: 

link). 65 Play — begins playing from the beginning of the clip 

The dynamic story control registers finks with the link • Stop— stops playing, sets current position back to 

manager as they are created. Also, the dynamic story control beginning of clip 
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• Pause — stops playing, maintains current position property stream 584 is not needed if properties are not 

• Resume — begins playing from current position None supported by the object type. The handle table stream is not 
of these actions take any parameters. required if the object doesn't reference anything. 

k. Wraps (Intrusions) The COS is the basic component which mediates persis- 

The process of getting a wrap placed correctly in a 5 tent storage of MPS objects into an OLE compound docu- 

dynamic story control, outline control, or story control has rnent file. It is the go-between for both MPS applications and 

three steps: tools and also mediates access to a COS compound docu- 

1) The author places the picture in a content stream, and ment on behalf of the Object Broker 550 (FIG. 10). 
marks it as a wrap. Th e Object Broker 550 provides for peer-to-peer commu- 

2) The title designer (not the author) decides where the 10 nicatioc for distribut ed object needs of the MP system 100. 
wraps should be placed within the control 0b J ect Broker 550 resides on an ? ma chine that connects 

awi/u *u ™ . m *u *l « < into the MP system 100 — either as publisher, server site, or 

3) When the customer runs the tide, the control code sees , , . 7 * r 
♦u i | j' . « . , customer (client). 

the wrap and places it according to the designer s r™ ~. ^ . ' , __ A . , , ... c 
«• Tne Object Broker 550 interacts with the COS for com- 

~ c * 4 t j ■ ijr i* * 4 l' ■ i *j iL . 15 pound document access and fundamentally transacts with 

Ot course, the diniculty in this is to identify the means by w DC .■ . ft ,. „. . ~ T ~ o7« m n ^ * 

. • . tU , J u -*u . . ii i • MPS client software applications via OLE COM RPC. In the 

which authors mark a wrap as such without actually placing P . , . c xt . c KT . 

a u uuj- . i r i- case or operating m the context of Microsoft Network 

it, and by which designers set rules for placing wraps r\ v c • sCm^\ iL . ™ , . 

... ♦ • i i j c u . »l T-if- i. Online Service (MOS), the Object Broker 550 also makes 

without prior knowledge of what the wraps are. This prob- rw^c X jd^/ \ \i n u • > 

. i , , ■ 4 i Tn. l • i_. use or MOSMPC (remote procedure call mechanism). MPC 

lem is solved by using styles. The user has eight wrap styles „ n • „ . f ™ . \ 0 . , ™- . „ . -J 

iudc n , DJ ., . . 20 is used for Object Broker-to-Object Broker, peer-to-peer 

available within the MPS Document Editor authoring envi- • . ro ^ t - r , 1 ' ™ Xjf . J , , t . f t 

o „ # & interactions. OLE COM RPC is used for both chent-to- 

ronment. ^ „ , , , 

C. Architectural Structures ^ ^ J SKVer ,.' nd * e ^er-to-server scenario 

His section will describe the structures utilized during rJc 1°^* connectlons and P ro,ocols "PP 01 ** COM 

the title creation and title publishing processes. _ e rnc . . . 4 , , 4 , 4 . „ 

^ i- & r 25 Ine COS component library is intended to be statically 

Referring now to FIGS. 11a, Ub and lie, a structural ^ , int ° aDy pi f C °f "™8 its 11 

diagram of the COS component of the MP system MM) will Z ?P ° T 1 ^'^S^™^ C ° S 

be described. As previously shown in FIG 10, wherein a % ™* "? a ^^. ,h r gh , a „ C++ ™ 6 

Publisher COS 544, a Server COS 540 and a Viewer COS m ° bjeCt B "* 6r 5 f ° 15 ^Pl 61 ^ 85 a P"** 88 u »ng 
548 where described, the COS is an essential component of 30 ^-^^ing concurrency to service 

^Z^ ! 1 ^ MP V*? h 10 °; , k ,„ MP P aLtr^of the COS is that of a COS- 

i£f « ^ H^^Tr, ^ J 86 ^ k T loca) 'y «»P«> handle to a " °>>ject moniker, which in turn 

system 100. Several different abstractions are exposed by the [ ^ object. Tne object moniker is key to 

COS a simple stream for arbitrary storage a discreet and 35 me of ^ J tem ^ object moniker ? , 

u^r-transparen. object storage for MFC CObject-denved da , oV .'^ (fe ^ ■> 

object classes, and object properties. A simple stream can be f *i„ t* j i 1* *c 

,.-1^ *^ rj.r i_. tation of the COS). It dual encapsulates information on 

used to contain an array of bytes of data for whatever > t . . o1 / c K , . t Al 4 . 

«„™o^ a r-nK \.^f a^^'a * ■ a either the local cached location of an object, and/or contains 

purpose^ CObject-denved object k managed pers.stend y me GlJ]D ^ J can be used in its 

by the COS once created and added to the system. Aproperty Mf - , , P t , , ^ # .. . . 

. j . ■ j • i. j- 40 retrieval from a remote location. The object moniker is also 

is a named typed value and can be associated with discreet JC c 4 * i- 

, • t ^ j jr # ™ . # - . 4l _ .j , used tor reterence count access tracking, object dirty status, 

objects and streams. The COS interface is thus divided . • _ # . r . ; ^ ™ 

J ^rto j j * c, , . . COS object type mformation, and a few other items. The 

among COS compound document file creation/opening/ u * -i , ' , , 

i • • i i-nc . u- * • object moniker must be used by the COS when actually 

closing, simple COS stream access, COS obiect persistence, A e . . . t ' A - 7 

» u- . - dereferencmg a COS object so that proper reference count 

and stream or object property access. _ ^ , • i4 J , r . i 

f-pt c 11 J - rr ' Air , a . 45 tracking, dirty status, and so forth, can be kept properly 

The tollowing references are useful for understanding the synchronized 

C ??r^ S ^ tCm " , ^ r , ^ AGUID is assigned to an object to uniquely distinguish 

OLE 2 Pro^ammer s Reference Volume One, Microsoft mat object. AGUID is generated by an OLE 2.0 API, known 

Corporation, 1994, Chapter 9— Persistent Storage as CoCreateGUID, using both a time identifier and a 

Interfaces and Functions; 50 machme (computer) identifier. This guarantees that any two 

Class Library User's Guide For the MFC Class Library, GUIDs produced on the same machine are unique because 

Microsoft Corporation, 1993, Chapter 14 — Files and they are produced at different times, and that any two GUIDs 

Serialization; produced at the same time are unique because they are 

OLE 2 Classes For the MFC Class Library, Microsoft produced on different machines. The presently preferred 

Corporation, 1993, class COleStreamFile 55 GUID is a 128 bit or 16 byte number. 

At the lowest level, the persistent object storage strategy Referring to FIG. 11c, an object moniker represented as a 

is to leverage OLE 2.0 capabilities for compound document moniker table record 630 in a moniker table, such as 

access, which includes an internal IStorage hierarchy and moniker table 600 shown in FIG. 11a, will now be 

IStreams for data content. Objects and property information described. A moniker table is persistent, that is, it is a stream 

describing objects are stored into discrete IStreams, which 60 at the root level of a COS. Structurally, the moniker table is 

are organized within a hierarchy of IStorages. preferably implemented as a sparse array, wherein if the 

Referring to FIG. 116, an object 580 is exemplary of an array doesn't need a slot in the table, the memory is released. 

IStorage, while IStreams for a typical object include an The moniker table record 630 includes information that 

object data stream 582, an object properties stream 584, and uniquely defines an object stored in the COS. The fields of 

a handle table stream 586. The object data stream 582 is 65 the record 630 include a GUID field 632, a publish date field 

required for the object, while the object properties stream 634, a handle or path to the storage 636, a set of flags 638, 

584, and the handle table stream 586 are optional. The and a persistence reference count 640. The path 636, also 
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called an object handle or CDPOHandle, is a DWORD (32 This COS belonging to the machine local Object Broker 

bits) that provides a short path or name of the storage. The may be hidden to protect the customer from inadvertently 

flags 638 indicate the existence of artifacts, that is, whether deleting or moving retrieved object data that is pertinent to 

the data stream 582, the properties stream 584 and the the user's downloaded title(s). The Object Broker is respon- 

handle table stream 586 exist in the COS for the current 5 sible for periodically expunging stale objects from this 

object. The persistence reference count 640 is only valid spccid COS so as to conserve user hard disk space, 

within a COS and is used for "garbage collection". When an 2. SuperCOS 

object is no longer used, signified by the persistence refer- Referring again to FIG, 11a, a discussion of an exemplary 

ence count 640 equal to zero, garbage collection removes the 5 J° now foUows - ^ Preferred superCOS is a 

object. When the object is removed, a tombstone is created to COS that references one or more COSes^which are known 

in the moniker table to indicate that the object did exist in the " ^ ^^^^ rni h * 

™ c . . t . * . u . * *i root portion 572 and two subCOSes, a title COS 590 and a 

COS at some Ume m the past. The tombstone is a moniker CQ J m fo]der CQS $n , Q ^ [qo{ Q sn of ^ 

with a flag which indicates that the object of that GUID is superCO s 570, there is a storage for types. As shown in FIG. 

extmct. The object storage is purged but the moniker H fl , there is a project type IStorage 576 off the root of the 

remains. 15 superCOS 570 which references one or more storages for 

The object moniker is also instrumental in the MPS each object of the type, which is project in this instance. The 

scheme for local object caching. The GUID identity of an project object 578 has the three IStreams, such as the 

object encapsulated in an object moniker is used to seek and streams 582, 584, and 586, as previously described in 

identify the appropriate object remotely from the machine it conjunction with FIG. 116. The project object 578 keeps 

is requested for. A user may have downloaded a title COS 20 track of the subCOSes 590 and 592. That is, the object data 

from an on-line MSN server, such as MPS server 246 (FIG, stream 579 of the project object 578 references each sub- 

3). This title is stripped of all objects leaving only a moniker COS created by the publisher for the current project. The 

to the root title object. Attempting to view this title and thus root portion 572 also includes a moniker table 574. Since the 

attempting to access its objects forces absent objects to be root portion 572 preferably only includes a project object 

remotely retrieved via the Object Broker. The objects 25 578, the moniker table 574 only has one record and is a 

become stored locally (in the Viewer COS 548) with the persistent stream off the root of the superCOS 570. 

Object Broker 550 on the machine initiating the request. The relationship between a title and a COS is one to one, 

Viewing a title having locally cached objects then subse- that is, there is one COS per title. This relationship follows 

quently offers much higher performance. Yet, the objects from the concept that a COS is a distinct set of objects that 

comprising this title can be tracked and updated over time, 30 reference each other. In the present embodiment, a title does 

such that the title remains fresh with the current edition not reference another title within a superCOS, but this 

mastered by a publisher. When a title is on a customer's capability is provided in another embodiment, 

machine, it is most appropriate to think of the title's objects The title COS 590 includes a moniker table 600 and one 

as being remotely served and mastered, but locally cached or more type storages 594. The type storage could be for a 

for optimal user performance of perusal. 35 title, section, page, style sheet or other MPS objects. In this 

The Object Broker component resides upon all nodes in example, type storage 594 references an object 596 and an 

the MP system 100 comprising publishers, title servers, and object 598. A moniker table record is created for each object 

client end users. The Object Broker primarily fields requests in the COS 590. In general, a COS has "n" types, and within 

for objects specified by GUID. If one Object Broker server the type storage, there may be "m" objects, 

cannot fulfill an object request, it attempts to relay the 40 The content folder COS 592 includes a moniker table 601 

request to server sites that it knows about. The object, when and a type storage 602, which in the preferred embodiment 

and if found, can later be propagated to its final destination is of a folder type. The storage 602 references other 

in a store-and-forward manner, or the requested object can containers, such as a folder (also called a subfolder) 604, and 

be transmitted between the point of its discovery to the point content 606. The use of sub folders is optional, but they serve 

of its request without store-and-forward copies of it being 45 to help organize objects. The content folder COS 592 

retained at intermediate server sites. This is governed by provides a means of publishing fresh content. The publisher 

system configuration settings for each Object Broker site could create a title stored in the title COS 590 for which the 

and the administration policy of that site. layout changes very infrequently, if at all. Then, periodically 

The nature of the ultimate repository of an object can be (e.g., daily, weekly, monthly), the publisher can publish new 

rather flexible under this scheme. The key item is the object so content (e.g., stories, images, bitmaps, and so forth) in the 

moniker and the GUID it encapsulates. The object moniker content folder 592. 

could be extended so as to provide for arbitrary mechanisms Referring again to FIG. He, a GUID map 620 will be 

by which to synthesize the actual object at object request described. When a COS is opened, the MPS reads out the 

occurrences. The object may reside in a COS IStream. The moniker table and creates the GUID map 620. The GUID 

object could reside in a file system file external to the title 55 map 620 is created in the RAM of the computer where the 

COS file. Or the object could reside in some other foreign COS exists in the form of a hash table structure. The map 

object data base and thus require some protocol interaction 620 is created by reading each moniker table record to 

in conjunction to that data base to retrieve the object (and extract the GUID, such as GUIDx 622, and storing the 

perhaps later commit modifications to the object). This GUID and a pointer 624 to the corresponding moniker table 

scheme of local caching effectively shields MPS client 60 record 630 in the GUID map 620. Each GUID stored in the 

applications, tools, custom OLE controls, and so forth from GUID map 620 has a pointer to one moniker table record, 

having to have specific knowledge as to how the Object Thus, given a GUID, the system can access the moniker 

Broker go-between process actual does its task of retrieving which provides the path to get the corresponding object and 

the desired object and locally caching it. its artifacts. 

It is important to note that when an object becomes locally 65 3. Title COS 

cached, it resides in a COS IStream — within a special COS Referring to FIG. 12, an exemplary title COS 591 will be 

belonging to the machine local Object Broker (see FIG. 16). described. The title COS 591 is similar to the title COS 590 
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of FIG. 11a, but is enlarged to show a plurality of different tory. In contrast, a customer superCOS, such as at customer 

type storages and referenced objects. The title COS 591 workstation 182 (FIG. 2) is a cache for those objects which 

includes a moniker table 600 with a record 680-690 for each have been transmitted to the customer, and so may only 

object in the COS 591. The type storages in COS 591 contain a subset of the objects for a title, 

include a style sheet storage 650 having a default style sheet 5 d operation 

object 652 and a second style sheet object 654, a title storage ' ^ opera tional flow of publication and viewing will be 

660 having a title object 662, a section storage 664 having described in this section, 

a section object 666, a optional page wrapper storage 668 1 D es i gD er Process Flow 

having a page wrapper object 670 and a page storage 672 Refcrring now t0 FIG. 13, a title creation process 710 will 

having a page object 674 Each of the COS objects (title, 1Q ^ e described. This process 710 is preferably performed at the 

section, folder, content folder, root content folder, proxy ... , . . f. - x . 

table) nominally has the three artifacts for data, properties, P ubh ? er -T ™ fJ ?u l ^ 

and handle table as previously described in conjunction with 

FIG, Hb. The exceptions are that window, page, content, (HG. 5). 

search, and style sheet objects normally do not have a handle Beginning at a start state 712, the designer environment is 

table artifact, e.g., default style sheet 652 has a data stream 15 evoked by the publisher 102 (FIG. 1). In the presently 

656 and property stream 658. These objects are leaf objects preferred embodiment, the publisher clicks on a Designer 

that do not reference other objects. Another exception is that icon on the Windows 95 desktop or selects Designer through 

a certain type of page object, the virtual page object 674, the menu system of Windows 95. In either case, the bbde- 

normally only has a data artifact 673. sign.exe program, previously described, is initiated. Moving 

In the presently preferred embodiment, the optional page 20 to a state 714, the process 710 creates a new object 716, e.g., 

wrapper object 670, which has a data artifact 669 and a a project, a title a content folder and so forth. This state is 

properties artifact 671, is included as a design convenience. part of the viewdll.dll. 

In another embodiment of the system 100, the page wrapper Proceeding to a decision state 718, the process 710 

storage 668 and page wrapper object 670 are not utilized. determines if the object is a project object. If so, the process 

When a new title is created, the title references a default 25 710 continues at a state 720 and creates a new COS file to 

window object, having standard window properties, and a represent the project. This state is part of the cos.dll. If 

default style sheet object. The title designer can choose to decision state 718 determines that the object is not a project 

modify the default object, and thus create, a new window object, the process 710 moves to a decision state 722 to 

object to exhibit the behavior desired for the window. A determine if the object is a title or root content folder. If 80, 

similar process can be done for the style sheet object. 30 the process 710 advances to a state 724 and creates a new 

Ahandle table 663 for the title object 662 has information subCOS, such as subCOS 590 or 592 (FIG. 11a) in the 

for all the sections in the title COS 591 (in this example, project file. This state is part of the cos.dll. 

there is only one section shown). The title object 662, If decision state 722 determines that the object is not a 

therefore, persistently has knowledge that the title object title or root content folder, the process 710 moves to a state 

662 references the section object 666. If a new section is 35 726 and associates the object with the parent container 

saved in the COS 591, the handle object 663 is updated with object, e.g., a section is associated with the title object. The 

information so as to reference the new section object. object handle (CDPOHandle) of the object, which is a 32-bit 

OLE Controls are not objects in the MP system 100. OLE local path, is added to the handle table stream of the parent 
controls are stored as data for the page in the data stream. container object. This state is part of the viewdll.dll. Pro- 
Each control has a Class ID and an OLE ID that is not a 40 ceeding to a state 728 to mark the properties of the parent 
GUID. The properties of some controls have a GUID to a object as "dirty". "Dirty" signifies that the memory image of 
style sheet. the parent object's properties has been modified. This state 

At the viewer COS 548 (FIG. 10), when a title is accessed is part of the cos.dll. 
for the first time, the title is preferably pulled over from the At the completion of state 720, 724 or 728, the process 
server COS 548. Alternatively, the title could be accessed 45 710 continues at a decision state 730 to determine if the user 
from the CD-ROM 124. When the tide is accessed for the desires to save the project. If so, the process 710 proceeds to 
first time, the Viewer 202 (FIG. 2) creates a moniker record state 732 and commits (i.e., stores) the new and dirty objects 
684 for the title object in the moniker table 600, gets the data to the appropriate COS. This state is part of the cos.dll. At 
stream and gets the handle stream. The Viewer 202 incre- the completion of the commit state 732, or if it was deter- 
mentally brings over objects into the viewer COS 548. 50 mined at decision state 730 that the project is not to be saved, 
Starting with the title object, the handle stream 663 has the the process continues at a decision state 734 and determines 
GUIDs for the other objects the title references. The viewer if the user desires to create another object. If so, the process 
202 initially puts the GUID for each object, for example, 710 loops back to state 714 to continue the title creation 
section object 666, in a moniker table record for that object process. If not, process 710 moves to end state 736, wherein 
(e.g., record 686 for section object 666). Later, when the 55 the designer environment is shut down, 
object is invoked or called, the Viewer 202 gets the rest of 2. Release Process Flow 
the moniker record information and stores it persistently in a. Client 

the moniker table 600 along with the object artifacts. Referring now to FIG. 14, a title publishing process 750 

4. MSN Server COS will be described. This process 750 is preferably performed 

A server COS, such as COS 544 in FIG. 10, is similar to 60 at the publisher workstation 180 (FIG. 2) and corresponds 

a superCOS 570, but does not utilize a project object 578 to with state 332 of the top level process 320 (FIG. 5). 

reference and keep track of the subCOSes. At a network Beginning at a start state 752, the process 750 moves to 

server, such as MPS server 246, the server COS does not state 754 and initiates the publish title process. This state is 

know what objects will be published to it and which subCOS part of the bbdesign.exe . Moving to a state 756, process 750 

the objects are associated with. 65 compress the COS objects. This state is part of the cos.dll. 

The server COS 544 contains titles in entirety, since they The process 750 continues to a decision state 758 to deter- 

are published there and the server acts as the master reposi- mine whether the publisher desires to publish to the remote 
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server. The designer is given the option to either release the object within the superCOS and which subCOS a particular 

title to the remote server 246 at the MSN Data Center 242 object resides within. When a new subCOS is added to a 

(FIG. 3) or to create a local COS file which contains all the superCOS, the subCOS directory of the superCOS is 

objects for that title. This is useful for local testing or for updated with the new subCOS. In addition, every object 

releasing a stand-alone title on a floppy or CD-ROM. 5 within the new subCOS is entered into the GUID lookup 

If the publisher desires to only release the title locally, the map with a reference to the new subCOS. At the completion 

process 750 proceeds to a state 760 and create a local COS of state 804, the title publishing process 790 (at the data 

file for the current title on the publisher's workstation. This center) finishes at an end state 806. 

state is part of the cos.dll. At the completion of state 760, Returning to the decision state 802, if the COS has been 

process 750 finishes the title publishing process at an end 10 previously published to the data center 242, process 790 

state 778. advances to a state 808 and extracts a copy of the previously 

If the publisher desires to release the title to the remote published subCOS from the superCOS of each MPS server 

server 246, as determined at decision state 758, the process 246 at the data center 242. This state is part of the cos.dll. 

750 proceeds to a decision state 762 and determines if there Continuing at a state 810, the process 790 updates each 

is a previously published timestamp for the COS. If so, the 15 subCOS copy with the new, modified, and deleted objects of 

process 750 moves to a state 764 and creates a temporary the received COS file. This state is part of the cos.dll. 

COS file which contains only those objects which are new, Moving to a state 812, the process 790 replaces the previ- 

modified or deleted since the last published timestamp. This ously published subCOS in the superCOS of each MPS 

state is part of the cos.dll. If there is no previously published server 246 with the newly updated subCOS. This state is part 

timestamp, as determined at decision state 762, process 750 20 of the cos.dll. At the completion of state 812, the title 

proceeds to a state 766 and creates a temporary COS file for publishing process 790 (at the data center) finishes at the end 

the entire title. This state is part of the cos.dll. state 806. 

At the completion of either state 764 or state 766, the 3. Object Broker Service 
process continues at a state 768 and transmits the temporary Referring now to FIG. 16, the Object Broker and its 
COS file to the data center 242 (FIG. 3). This state is part of 25 interaction with and fundamental use of the COS in the 
the mwrap.dll, previously described. Proceeding to a deci- context of the MP system 100 will be described. The COS 
sion state 770, the process 750 determines if the data center 544 (which may be a superCOS if more than one COS is 
has confirmed the publish operation. If not, the process 750 present) and the Object Broker 546 are shown at the pub- 
moves to a state 772 and notifies the publisher of a failure lisher location 102. The COS 548 (which may be a super- 
to publish. This state is part of the bbdesign.exe. After the 30 COS if more than one COS is present) and the Object Broker 
publisher is notified, process 750 finishes the title publishing 550 are shown at the customer location 160. The superCOS 
process at the end state 778. 540 (a plurality of title COSes 854 and title COS 840 are 

If the data center has confirmed the publish operation, as shown in this example) and the Object Broker 542 are shown 

determined at the decision state 770, the process 750 at the server 246. A title 840 at the publisher COS 544 

advances to a state 774 and timestamps the current publish 35 contains all the objects (signified by the bold circles for truly 

date in the root moniker of the title. This state is part of the present objects) while the Object Broker 546 does not 

cos.dll. Then, at a state 776, the process 750 notifies the contain any objects (signified by the lighter circles for 

publisher of a successful publish operation. This state is part objects not truly present) for that title. On the server 246, all 

of the bbdesign.exe. After the publisher is notified, process the objects are deposited into the Object Broker 542, and 

750 finishes the title publishing process at the end state 778. 40 only a skeleton title 840 remains (title with all the object 

b. Server removed having just a root moniker). At the customer site 

Referring now to FIG. 15, a title publishing process 790 160, the skeleton title 840 is used to start viewing a title, and 

will be described. This process 750 is preferably performed the Object Broker 550 will contain those object necessary to 

at the MSN data center 242 (FIG. 3) and corresponds with view the title. 

state 332 of the top level process 320 (FIG. 5). 45 As previously described, the COS can be considered an 

Beginning at a start state 792, the process 790 moves to OLE compound document file utilized for persistent object 

state 794 and receives the COS file transmitted from the storage by the MP system 100. COS manager is the code 

publisher workstation 180 (as described in conjunction with associated with accessing a COS file and is an implemeo- 

FIG. 14), This state is part of the bbobsvc.dll. Moving to a tation of the IObjectStore interface, residing in the COS 

state 796, the process 790 notifies the Arbiter 252 (FIG. 3) 50 DLL. The COS manager is the intermediary between a client 

at the data center 242 of the received COS file. This state is application and this object storage compound document. It 

part of the bbobsvc.dll. Advancing to a state 798, the Arbiter manages the insertion and retrieval of persistent objects to 

252 notifies each MPS server replicant (such as 246a, 246b, the COS compound document, at the lowest level. 

246c, as shown in FIG. 3) of the received COS file. This The COS manager can field object retrieval requests 

state is part of the MSN arbiter service. 55 locally from its COS context. In the event the requested 

Proceeding to a state 800, each MPS server replicant 246 object is not physically present, the COS manager can in 

updates its existing superCOS with objects from the turn field the request to the host machine Object Broker (the 

received COS file. This state is part of the bbobsvc.dll. To local Object Broker at the customer workstation 182, for 

facilitate this update, process 790 moves to a decision state example). The local Object Broker may have the requested 

802 to determine if the COS has been previously published 60 object cached on the local host machine, but if not, it will 

to the data center 242. If not, process 790 proceeds to a state seek to obtain the requested object from a connected remote 

804 and adds the entire received COS file as a new subCOS server 246 at the data center 242 (FIG. 3). But this chain of 

in the superCOS of each MPS server 246 at the data center events may continue in the event that the remote server 246 

242. This state is part of the cos.dll. A GUID lookup map and does not have the requested object cached either, in which 

subCOS directory in the root portion of the superCOS is 65 case it will in turn propagate the request to servers that it is 

updated to reference the new subCOS. Every superCOS has connected to. If eventually found, the requested object may 

a GUID lookup map and a subCOS directory to identify each be either directly forwarded to the original requester 
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machine's Object Broker, or it may be store -and- forward While executing as a process on a server site 242, the 

propagated through the chain of connected server sites. At Object Broker is acting as a background task for fulfilling 

each server point a MPS Object Broker is the mediator for any in-coming object requests, title COS updates, and title 

the object request. This is the Object Broker's primary role. COS publish operations. The Object Broker implementation 

The COS Object Broker interface is implemented in the 5 is as a Win32 32-bit executable and as such, takes advantage 

convention of an OLE COM custom class and is called of win32 multi . threadmg ^ as t0 xrwkc multiple cbent 

lUbjectBroker. requests. Access to the Object Broker's hidden file COS 

Hsh t°: S'n^^^^J^ lr P , eC1 ^ ob J ect cache also supports multiple process and multiple 

hsbiag operation 842 on behalf of MPS publishing si es, ,u' A „„„„ n. . .u i-n<? . . . 

such Is publisher 102. A fiiUy produced publisher's COS thread aCCeSSeS - ^ *> lbe C0S mana S er must t0 ° ^PP 0 ' 1 

document, known as a title 840, is propagated to server sites 10 COT ^ lS ^V*?i?l . , T 

242 via use of this publishing operation 842. During this C P^ber-side Implementation 

process, the title COS 840 is stripped of its objects to where From a P ubusher Slte 102 perspective, the Object Broker 

only object moniker tables remain in the title COS 840 at the offers a um 9 ue publish 842 service. Publishing a title COS 

server superCOS 540— and perhaps optionally a select 840 conveys the title COS to a server site 242. The Object 

group of exempt objects that continue to reside in the COS 15 Broker 546 of the publisher-site machine 180 interacts with 

840. Most of the actual objects of this title COS 840 are the Object Broker 542 of the server-site machine 246. The 

propagated to and update the server's Object Broker local COS compound document file, of which the title COS 840 

object cache 832. The Object Broker local object cache 832 primarily consist of, is transported to the server site 242 

is a COS file made hidden via the file system. As previously where it is stored again as a file in the file system of the 

described, an object moniker is a special object proxy that is 20 server 246. 

retained in a COS. Every object that can be referenced via The title COS 840 is entered and stored in the superCOS 

a given COS has an object moniker record in that COS. The 832 of the server site Object Broker 542. All objects receive 

moniker encapsulates a GUID identity of the object it a GUID identity at creation time in the designer environment 

represents. In the case of an external file object, the moniker 194 (FIG. 2). Objects which have a pre-existing GUID 

provides path information to locate the file and is known as 25 identity update older versions of themselves in the local 

a file moniker. cache 832 upon collision. Discreet objects are accessible or 

When a customer 160 wishes to obtain a title from the retrievable in confederation to the server site Object Broker 

server 246 (when connected to the preferred network), the 542 via their GUID identity. The GUID identity is used by 

system performs a file copy of the title COS 840 to the file the Object Broker 542 as a lookup key into its map of cached 

system of the user's local workstation 182. The customer 30 objects. 

may then proceed to view the downloaded title in the MPS A given published title. COS, such as title COS 842, also 

viewer application. This action forces object dereferencing. possesses a unique identity (subsumed from the GUID of its 

The local COS manager will be unable to locally satisfy root-most object). It remains so uniquely identified at the 

these resulting object request from within the stripped-down server site 242 to which it is published 842. Future attempts 

title COS 840 at the customer's workstation 182 and will 35 to republish the title result in updating the version of it that 

field them in the manner of the Object Broker scenario exist on the server site 242. The identifying GUID of the title 

described previously. Once this title is downloaded to a COS is retained at the publishing site 102. 

customer's workstation 182, the title is thereafter kept up to From the publisher site 102 it is also possible to publish 

date with the latest version of the publisher's title objects via folders of tide content as a content folder subCOS 592 (FIG. 

on-going connection sessions to the server 246 over time 40 11a) in a manner similar to that of a title subCOS. Prior to 

and the MPS Object Broker mechanism operating upon on publishing a folder of content, the individual content files 

all point nodes in the distributed system. must be linked into the respective title. Hence, a complete 

a. Object Broker Operation title may consist of a title COS of objects plus a folder of 
The MPS COS Object Broker supports two primary content objects, where content objects consist of a directory 

services or operations: object request retrieval and object 45 hierarchy of discreet files that have been linked into the title 

cache updating and title publishing to a server, where the in various usage relationships. A plurality of published 

title is stripped bare of objects suitable for end user down- content folder subCOSes 856 are shown in the local COS 

loading. In addition, the Object Broker also automates object cache 832 of the server site Object Broker 542. 

aging and expunging from its object cache, maintain an A published content folder is known by the Object Broker 

object update list on a per title basis, and maintain a list of 50 GUID identity of the local machine from which the folder 

other object broker servers that have been or can be con- originates (the publisher's machine 180). It is further pos- 

nected to. sible to use the name of the folder as a lookup key in 

b. Implementation Description conjunction to the Object Broker GUID. The server site 
The Object Broker executes as a process upon its host Object Broker 542 retains archives of the content folder 

machine, such as the publisher workstation 180. It operates 55 from previous publishings of the folder. It is possible to 

as a server for both local processes and remote client query the server Object Broker 542 and enumerate all 

processes executing on external machines. Access to the retained archives of a particular published folder. 

Object Broker interface from external machines is made via d. Customer-side Implementation 

the Remote Procedure Call (RPC) protocol. In the case of The primary Object Broker service from the customer site 

Microsoft Network client-to-server access, the protocol of 60 perspective is object retrieval, coupled with local caching of 

interaction is MPC. M PC is used for object broker-to-object objects, and the periodic expunging of stale objects from the 

broker dialog and is encapsulated in the Object Broker; cache, so as to prevent inordinate usage of the end-user's 

client code is shielded from MPC via the Object Broker precious hard disk space. 

public interface. Thus, local machine interprocess access of Customers will be able-to download published title COS 

the Object Broker interface is via the OLE 2 COM conven- 65 files from server sites 242. Attempting to view a downloaded 

tion where proper interprocess marshaling must take place title COS 840 at the customer COS 548 via the MPS Viewer 

on client/server interactions. application effects the forcing of object requests. For 
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example, the COS 840 in use by the Viewer application 
attempts to load a title object and discovers that it is missing. 
Consequently, the COS manager then invokes the local 
Object Broker API to retrieve the object by supplying the 
absent object's GUID identity to the Object Broker 550. Id 5 
this context, local refers to the object broker 550 operating 
at the site of the customer's workstation 182. The object's 
GUID is encapsulated within the object moniker data struc- 
ture. The root moniker, in turn, is contained in the moniker 
table (see table 600, FIG. 12) within the title COS. 1Q 

The local Object Broker 550 then attempts to look-up the 
object, such as object 850, within its local object cache. 
Some objects, such as object 848, are present in the cache 
(indicated by a bold object circle). On a cache miss, such as 
for object 850 (shown as a lighter object circle), the local 
Object Broker dispatches an object request 852 to the Object 15 
Broker at a remote server site 242 via RPC or MPC. If 
discovered remotely, the requested object is propagated to 
the customers machine and is entered and stored into a local 
Object Broker cache 834. The COS manager, on behalf of 
the Viewer application, then completes the object load from 20 
the Object Broker cache 834 and henceforth retrieves the 
object from there, until a point in time when or if the object 
becomes expunged from the cache (in which case the remote 
retrieval sequence is reprised so as to satisfy any new request 
for the object). 25 

The result of this process is that the title COS 840 can be 
mastered by a publisher 102, published to a server 246, and 
then periodic updates to the contents of the title (which 
would perhaps be objects comprising the title itself or a 
published content folder) could then be made by the pub- 30 
lisher 102. By subscribing to a title, customers could acquire 
its current contents during log-on sessions while connected 
to a title server 246. 

A title COS 840 downloaded to a customer's machine 
182, by these mechanisms described, forces retrieval of the 35 
most current published content information. This would 
happen by interactively browsing a title or else by the home 
delivery of the title, which would be enabled while sub- 
scribing to the title. 

As briefly mentioned above, home delivery is a special 40 
scheduled service where the customer's machine connects to 
a server site 242 at off-peak hours. The customer's machine 
automatically acquires the latest published title by retrieving 
all the objects necessary to view the title and storing the 
objects in superCOS caches. 45 

e. Server Implementation 

The server 246 is the public repository site of published 
titles and published content folders. A stripped-down pub- 
lished title COS, such as COS 840, is retained in the file 
system of the server 246. Hence the customer workstation 50 
182 can retrieve a title by merely performing a file copy of 
the title file to their local machine's file system. Published 
content folders 856 result in the creation of subCOS entries 
that hierarchically reside under the root Object Broker COS 
832. The objects contained by a content folder, which were 55 
discreet files on the publisher site, become COS IStream 
objects within their respective content folder subCOS. Cli- 
ent end-users cannot directly access the objects comprising 
content folders. 

In either case of title COS objects or content objects, both 60 
are ultimately identified by a GUID. The server Object 
Broker 542 accepts their GUID as a key by which to look 
them up for object retrieval purposes. The MPS publisher's 
tool suite provides for assigning GUIDs to content objects 
by an OLE API at the point in time that they are linked into 65 
a title that is under preparation. Additionally, it is possible to 
key for a content folder. 



A title COS can be keyed in confederation to the server 
Object Broker 542, by supplying its GUID identity. A title 
COS 840 is not in any way automatically archived by the 
server Object Broker 542. Once created, a title COS 840 and 
its contained objects tend to be very long lived and are not 
updated on as frequent a basis as are content objects. 
Consequently, a publisher site 102 is responsible in totality 
for title COS archiving. A publisher site 102 must also retain 
a stub of a published title COS 840. This stub title COS need 
only contain the object moniker of the root-most COS 
object — which encapsulates the GUID of the root-most 
object. This root-most object GUID identifies the title COS 
as when it was published to a server Object Broker 542. 

f. COS External Files 

Objects of a COS are referenced with a 32-bit locally- 
scoped object handles. Every object known by a COS has an 
object moniker entry in that COS. Objects which are actually 
contained in the COS are placed into IStreams that are 
hierarchically scoped from the root IStorage of the COS. 

In the case of content files as found under a content folder, 
these are not made to be contained internally in a COS (this 
is only the case, however, for a publisher site workstation 
102), but instead are linked to a COS by use of a special file 
link moniker mechanism. Such external files can also be 
made to have links to other files in a usage relationship 
manner. All of these links involving external content files 
cause an object moniker entry to be generated in their 
respective COS (the subCOS instantiated and contained 
within the local Object Broker COS) for the link collect ion 
of items from a specified content folder. 

V. VIEWER DETAIL 

A. Overview 

1. Subsystem and Interfaces 

This section describes the viewer component (also known 
as the Viewer 202, FIG. 2) for the MPS architecture. The 
Viewer 202 is responsible for synthesizing a title into its 
composed format. This component can be described as 
providing the run -time view of a title, while the project 
editor component provides a design-time view of a title. 

a. Subsystem and Interface Overview 

The viewer component, synthesizes the set of objects, 
which define a title, into a rich multi-media document which 
is viewed and navigated on the client machine. The synthesis 
process consists of two basic functions: acquiring the con- 
tent and composing the content. In the case of a static title 
(one which does not make use of search objects or links to 
external content), the content acquisition step is not 
necessary, as all of the content required to compose the title 
is already defined in the title. A dynamic title requires the 
acquisition step to resolve search objects or links, acquire 
content, and insert it into the title. This process of a acquiring 
content can be applied successively, appending or replacing 
previously acquired content in order to update the instance 
of the title being synthesized. Having acquired the content, 
the title can now be composed and rendered on the client 
machine for viewing. The viewer component provides addi- 
tional interfaces for navigating and managing hyper-text 
links while a title is being viewed by the client. Several 
subsystems are used to perform this process of synthesizing 
a run-time view of a title. 

At the top-level there is a general viewer subsystem and 
interface (1 Viewer) for initiating the synthesis of a given 
title. This interface includes methods for instigating the 
content acquisition process which creates or updates an 
instance of a title (pressed title or issue). There are also 
methods for initiating the composition and viewing of one of 
these instances. Finally, there are methods for storing or 
archiving one of these instances (back pressing or back 
issue). 
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The content acquisition subsystem is invoked by the 
general viewer subsystem to resolve search objects, retrieve 
content attracted to the search objects, and insert the 
retrieved content into the structure of the title instance being 
created or updated. The acquisition subsystem can be 5 
prompted to acquire content for the entire title or an indi- 
vidual section. This capability allows individual sections to 
be scheduled for update. The content acquisition subsystem 
traverses the given title or section looking for search objects 
to resolve. The IResolveMagnet interface is used to retrieve 10 
a list of content IDs (path based or GUID based) for each 
search object. These content IDs are references to the actual 
content objects (MPML, graphics, audio, video, and so 
forth) and are inserted into the tide instance in the appro- 
priate section, associating that content with that section. 15 

Depending upon the viewer mode, home delivery or 
browse, the content acquisition subsystem may or may not 
actually retrieve the content objects referenced by the con- 
tent IDs, In home delivery mode, the BSBobjectBroker 
interface is used to retrieve the actual content objects 20 
immediately and cache them in the local object store. In 
browse mode, the actual content is not retrieved until it is 
required for composition (is to be viewed by the user). When 
the user is browsing a title interactively, the mechanism for 
retrieving content may be through the IContentServer or 25 
IMediaServer interfaces. These interfaces support the trans- 
mission of specific content objects in an efficient manner. 
For instance, a MPML file may be pre-parsed on the server 
and only a partially resolved parse-tree transmitted to the 
client for composing common tags within Infomaps, such as 30 
abstracts or table of content entries. An Infomap is a special 
kind of control that provides automatic display and naviga- 
tion capabilities. Graphics may be transmitted as progressive 
renderings, audio as short sound bites, video as first frame, 
and so forth. 35 

When the viewer subsystem is prompted to compose a 
given instance of a title, the first step is to create a parse tree 
which represents the entire structure of the title. The actual 
parsing of the MPML content can take place on either the 
server or within the viewer component on the customer 40 
workstation. The result is a complete tree for the entire title, 
including the structure inferred by the title at the top of the 
tree, and the parse trees for each individual MPML object at 
the bottom of the tree. The parse tree may or may not be fully 
resolved with the content depending on the viewer mode. It 45 
is at the parse tree creation step that sorting algorithms can 
be applied to order the content that is placed into the tree. 
This parse tree exposes an IParseTree interface which is 
used by the Infomap and OLE dynamic story controls to 
retrieve the relevant tagged elements from the title structure. 50 

In addition to the parse tree, a form block manager is 
initialized to manage and track which elements of the parse 
tree structure are composed onto which pages. This page 
block manager tracks the page breaks for the content, and 
provide an IPSF interface for the OLE dynamic story control 55 
to identify where in the parse tree to start composing on a 
given page. 

A navigation subsystem provides the INavigate interface 
of which controls, menus, internal and external scripts, and 
so forth can be used to manipulate the view of the tide. The 60 
navigation subsystem uses the page block manager and 
parse tree to manage the creation, composition, and viewing 
of pages. 

The viewer component also contains a Link Manager 
subsystem which provides the ILinkManager interface. This 65 
interface is used by Infomap and OLE dynamic story 
controls to register and resolve hyper-text links within the 



title. These links may be either synthesized (Infomap 
control), or obtained by a tagged-link provided within some 
content (dynamic story control). 

b. Subsystem and Interface Detail 

The subsystems and interfaces provided by the viewer 
component as well as the interfaces which are required from 
other components will now be further described. 

i) Provided Interfaces 

The Viewer provides the following interfaces, all of which 
are contained in the VIEWDLL DLL: 
IViewer — Provides methods for acquiring content, 
composing, viewing, and archiving titles. 
BOOL Open (const CString& filename) 

Open the given title file for synthesis by this viewer 
object. The viewer object assumes that it has the 
right to modify this file with regards to acquiring 
content. The creator of the viewer object should 
assume the responsibility for duplicating the original 
title file, if necessary. 
BOOL ArchiveAs (const CString& filename) 

Create an archive of the currently open title into the 
given filename. This method causes all of the locally 
cached objects within the client object store which 
are referenced by the title to be copied into the 
archive file. This operation produces a completely 
self-contained title which can be viewed in the 
distant future without regard to objects having been 
updated or removed from the local cache or server. 
BOOLAcquireContent (BOOL cacheLocal =TRUE) 
Acquire content for the currently open title. This 
method iterates through the entire title resolving 
active search objects with the server. The content IDs 
resolved by the search objects are inserted into the 
proper section, associating the content with the title. 
By default, the actual objects are downloaded from 
the server and cached in the local object store (home 
delivery mode). Providing a FALSE cacheLocal 
parameter will defer the download of the actual 
object until it is viewed by the user (browse mode). 
BOOLAcquireContent (const CString& sectpath, BOOL 
cacheLocal =TRUE) 

Acquire content for a given section of the currendy 
open title. Identical to the previous method, but 
reduces the scope of the content acquisition to a 
given section (full path name). This allows sections 
to be scheduled for acquisition and update on an 
individual basis. 
BOOL Compose ( ) 

Compose the currently open title for viewing. This 
method creates a parse tree for the entire title struc- 
ture and initialize a view block table for managing 
the composition of pages. It then identifies the first 
page of the tide, composes it, and displays it to the 
user. Subsequent navigation through the title causes 
other pages to be composed and displayed. 
CElementNode* GetRootNode ( ) const 

Returns the root node of the parse tree for the currendy 
composed title. The IParseTree interface can then be 
used to locate specific elements within the tide. Note 
that the root node is only available when a tide has 
been composed, otherwise this method returns 
NULL. 

IParseTree — Provides methods for walking the nodes of the 
parse tree and for extracting a list of specific element nodes 
from the parse tree, 

IPSF — Provides methods for retrieving the next element 
node and character position for composing the dynamic 
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story control on a page. This interface is used exclusively by 
the dynamic story controls for determining the starting point 
of composition for a given page. The dynamic story control 
uses the IParseTree interface to retrieve each subsequent 
node of the tree, until the entire dynamic story control region 
has been composed or there is no more content to compose. 
When composition is complete, the dynamic story control 
marks the ending node and character position with another 
method of this interface. 
CElementNode* GetNextPSFNode (DWORD formID, 
CElementNode** startNode, DWORD& startPos) 
Called by a dynamic story control to retrieve the story 
node, starting element node, and character position 
to start composing the page identified by the given 
formID. The returned node is the story node within 
the overall title parse tree structure. The startNode is 
set to the specific element node at which composition 
should begin. The startPos is set to the character 
position within that specific element node, 
void MarkLastPSFNode (DWORD formID, CElement- 
Node* endNode, DWORD endPos 
=kNotDoneReodering) 

Called by a dynamic story control to mark the element 
node and position at which composition of the 
dynamic story flow for the given page has ended. 
This information is stored in the view block table 
along with the starting story node, element node, and 
position. If the end of a story is parsed through and 
the dynamic story control can continue composing 
text, it will mark the end of the story with an endpos 
of kNotDoneRendering and will call GetNextPSFN- 
ode to continue composing the next story, if one 
exists. 

INavigate — Provides methods for navigating to various 
logical areas of the title being composed. 



BOOL 


GoNextForm ( ) 


BOOL 


GoPrevForm ( ) 


BOOL 


GoNextStory ( ) 


BOOL 


GoPrcvStory ( ) 


BOOL 


GoNextSection ( BOOL wrap Around =TRUE ) 


BOOL 


GoPrevSection ( BOOL wrapAround -TRUE ) 


BOOL 


GoTbScction ( const CStringft scctioaPath ) 


BOOL 


Go To Form ( const CSlring& form Name ) 



ILinkManager — Provides 
resolving finks. 



BOOL 


Resolvelink ( DWORD* UnkHandle ) 


DWORD 


Register Link ( const CLink& link, BOOL* 




isResolvcd) 


DWORD 


RegisterLink ( const CStringft sectionPath ) 


DWORD 


Register Link (DWORD content Han die, BOOL* 




isResolvcd) 


DWORD 


RegisterLink ( GUID contentID, BOOL* 




isResolvcd ) 



ii) Used Interfaces 
The Viewer uses the following interfaces: 
IResolveMagnet — Provides methods for resolving a search 
object (magnet) to a set of relevant content. 
IBBObjectBroker — Provides methods for acquiring an 
object from the server. 

IContentServer — Provides methods for acquiring content 
objects from the server in an efficient manner (this refers to 
tagged-text (MPML) objects). 
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IMediaServer — Provides methods for acquiring multi- 
media objects from the server in an efficient manner, which 
include graphics, video, and audio. 
ITitle — Provides methods for accessing and manipulating 
the collections of objects which define a title. 
ISection — Provides methods for accessing and manipulating 
the collections of objects which define a section. 
IForm — Provides methods for accessing and manipulating 
the properties and control properties which define a page. 
B. Viewer Structures 

1. Basic Title Parse Tree 

Referring to FIG. 17, an exemplary title tree 890 will now 
be described. A title tree is an in-memory representation of 
objects of a title in the MP system 100, wherein the objects 
are streams and storages in a COS. The title tree is utilized 
by the viewer component 202 to facilitate the viewing of a 
title by the customer. The title tree 890 comprises a root node 
and a series of nodes arranged below the root in a tree format 
to present a hierarchy of information. A tree is a well known 
software data structure. Each of the title, the sections, the 
subsections (if present), and the roots of the stories are the 
OLE storages, previously described. Each of these storages 
has a GUID assigned to it. Beneath a story root is a parsed 
tree representation of content that has been stored to a COS, 
known as a MPML parse tree. The MPML parse tree 
represents a parsed version of a structured story in a tree 
format, wherein any item that is tagged during the authoring 
phase has a node in the tree (including OLE objects). The 
MPML parse tree is further disclosed in a copending appli- 
cation also assigned to Microsoft Corporation, entitled 
"Structured Documents in a Publishing System," previously 
cited. At the base of the MPML parse tree are nodes, known 
as leaf nodes, that are the streams that store the data, such as 
text or embedded objects. Nodes above the leaf nodes are the 
storage nodes. 

The title tree begins with a title root 892. Associated with 
the title root 892 is a GUIDa that uniquely identifies the title. 
Below the root, at the next level of the title tree, are a series 
of sections. Section 1 is represented by a node 894 and has 
a GUIDb associated with it that uniquely identifies the 
section. Section 2 is represented by a node 896 and has a 
GUIDc associated with it. Section 3 is represented by a node 
898 has a GUIDd associated with it. 

In this example title tree 890, Section 894 has a story 1 
and a story 2. Story 1 is represented by a root 900 and has 
a GUIDe associated with it. Story 2 is represented by a root 
902 and has a GUI Df associated with it. In this example, the 
root 900 has a MPML parse tree 908 below it, which is a 
parsed version of the content identified by GUIDe. Below 
root 902 is a MPML parse tree 910. 

Section 896 has a story 3 represented by a root 904 having 
a GUIDg. Below root 904 is a MPML parse tree 912. Section 
898 has a story 4 represented by a node 906 having a 
GUIDb. Below root 906 is a MPML parse tree 914. 

The title tree 890 will be further referenced in conjunction 
with the viewer structures described in FIG. 18a and 18b. 

2. View Block Table 

Referring now to FIGS. 18a and 18b, structures used by 
the Viewer 202 (FIG. 2) in the viewing of a title will be 
described. When the Viewer 202 is initiated, either a title 
COS having a root is given to the Viewer, or the Viewer 
creates a new COS with a moniker. In either case, the Viewer 
202 opens the COS and accesses the title. The Viewer 202 
then creates a view block table, such as exemplary table 920, 
and synthesizes a title tree, such as title tree 890 (FIG. 17). 
These data structures are non-persistent. 

A view block table is an array of view block fists 
(described below), wherein there is one list per section of the 
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title. The exemplary view block table 920 is created by the of the located section to see if the requested story has already 

Viewer 202 by traversing the container portion (the top) of been composed onto a page. If so, the page is displayed to 

the title tree, beginning at the title root and proceeding down the customer. If not, a compose operation is called to 

each branch to the subsectioo level (if present), or the compose the requested story onto a page, followed by 

section level if there is no subsection for the section. Each 5 showing the composed story to the customer, 

container object is placed in the view block table 920. Using 3. Title Parse Tree 

the title tree 890 as an example, the table 920 has a title entry Referring to FIG. 19 a second exemplary title tree 990, 

922, corresponding to the root 892 of the title tree, a section that is different than the title tree described in conjunction 

1 entry 924, corresponding to the node 894, a section 2 entry with FIG. 17, will now be described. This title tree 990 is 

926, corresponding to the node 896, and a section 3 entry to expanded to include exemplary MPML parse trees and also 

928, corresponding to the node 898. shows how the tree need not be symmetrical. However, page 

The Viewer 202 traverses the view block table starting at nodes and control nodes, such as shown in FIG. 17, are not 

the title and proceeds to each section (and subsection, as illustrated in FIG. 19. 

applicable) as the view blocks are filled in. At each section, The title tree starts with a title root 992 having a GUIDa. 

the Viewer 202 determines whether the section has a page 15 Below the title root 992 are a section A represented by a node 

object. If not, the Viewer cannot display anything, and 994 having a GUlDb and a section B represented by a node 

proceeds to the next section. If there is at least one page in 996 having a GUIDc. Typically, a title is arranged with 

the section, the Viewer determines which page to view. At sections, and some of the sections may have subsections, 

the same time, in another thread, the Viewer initiates content Stories are inserted into either of the sections or subsections, 

acquisition. The stories for the current section in the title tree 20 However, stories may also be placed directly below the title 

are brought over from the server COS and are instantiated at root in the title tree, as exemplified by story C represented 

the Viewer 202. For a dynamic control within a section, by a node 1004 having GUIDg. Section 994 has a subsection 

search objects must be resolved to get the stories. The stories represented by a node 998 having a GUIDd. 

are received in the form of a MPML parse tree, and are Below subsection 998 is a story A represented by a root 

appended to the title tree below the corresponding section 25 1000 having a GUIDe. As shown in FIG. 19, the root 1000 

(or subsection, if applicable). A page composition and of story A is the root of a MPML parse tree. Below the root 

rendering process can begin as soon as a section having a 1000 of story A arc a head node 1006 and a body node 1008. 

page and a corresponding story are present at the Viewer The head node 1006 has a leaf node 1018 that, in this 

202. Thus, a story is composed as the Viewer 202 walks the example, is the abstract section of the story A at root 1000. 

tree. 30 The body node 1008 has a Headingl (HI) type of style 

There are two stories in the first section of the exemplary represented by a node 1020. Below the heading style is a leaf 

title tree 890 (FIG. 17). A view block list is created for each node 1040 having text content for the story. The text content 

section in the table 920 having a page. The view block list is in the form of a data stream. When instantiated by the 

is an object that contains a list of view blocks (one view Viewer 202 (FIG. 2), the style above it in the tree, style 

block per page in the section), and an array of handles to 35 Headingl, will be applied to the content. Also below body 

parse trees for the stories in the current section. In the 1008 is a Paragraph 1 (PI) style represented by a node 1020. 

example of FIG. 18, a view block list 930 is created for the The Paragraphl style has a leaf node 1042 below it that is 

section entry 924. The list 930 has a story 1 pointer 936 and also a data stream of text. 

a story 2 pointer 938 to the respective stories in the title tree Below the section B node 996 is a story B represented by 

890. A view block object is created by the Viewer 202 for 40 a root 1002 having a GUIDf. Below the story root 1002 is 

each page that contains a dynamic story control. The view another MPML parse tree having a head node 1010 and a 

block basically tracks which story and how far into the story body node 1012. The head node 1010 has a table of contents 

the composition and rendering process has progressed at the (TOC) leaf node 1024. The body node 1012 has a Heading2 

end of a page. There can be one or more view block per (H2) style node 1026, a Wrap Advertising (WA) style node 

story. 45 1028 and a Paragraph2 (P2) style node 1030. The Heading2 

Each section in the view block table contains page refer- style node 1026 has a leaf node 1044 representing a text 

ences. The page references are built up in the view block content stream. Below the Wrap Advertising style node 1028 

table (from the COS) as page requests are made. is a leaf node 1046 representing an embedded object stream. 

An exemplary view block 940, with initial field values, is The Paragraph2 style node 1030 has a leaf node 1048 for a 

shown in FIG. 18b. A beginning story index 956 is initialized 50 text stream. 

to zero since it is the first story in the section. An ending As previously mentioned, story C, which is represented 

story index 958 is also initially set to zero (start where end). by root 1004, is immediately beneath the title root 992. 

An end story node 960 (to which node the viewer Below the story root 1004 is a MPML parse tree having a 

progressed) is initially set to story 1. An end position index head node 1014. Beneath the bead node 1014 is an abstract 

962 (how far through a node) is initially set to zero. A page 55 leaf node 1032 containing a stream of an abstract for story 

type 964 is set to the type of page object currently being C. Also beneath the root 1004 is a body node 1016 having 

processed. A new view block is created using the ending a Headingl (HI) style node 1034, a Paragraphl (PI) style 

information from the previous view block as beginning node 1036 and a text stream leaf node 1038. Further, beneath 

information. In the example view block list 930, additional the Headingl style node 1034 is a text stream leaf node 1050. 

view blocks, view block 942 and view block 944, were 60 The Paragraphl style node 1036 further has a text leaf node 

created to complete the rendering of story 936 and story 938. 1052 below it. As previously mentioned, all leaf nodes are 

As the customer navigates through the title, e.g., by streams. All nodes above the leaf node level of the title tree 

activating a link to another story, a "resolve link" function are storages, 

locates the section for the desired story in the view block C. Operation 

table. The resolve link function then calls a "display story 1 65 1. Title Viewing Flow 

function and passes an index of the story to be displayed. Referring now to FIGS. 20a and 20b, a title viewing 

The display story function looks through the view block list process 1080 will be described. This process 1080 is per- 
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formed by the Viewer 202 at the customer workstation 182 state 1090 above, but thai is because this is separate code 

(FIG. 2) and corresponds with state 334 of the top level used whenever the customer interactively navigates to a 

process 320 (FIG. 5). section. This state is the ResolveForm function of the 

Beginning at a start state 1082, the process 1080 proceeds CBviewBlockList class and is part of viewdll.dll. 
to a state 1084 wherein the Viewer 202 (bbview.exe) is 5 The process 1080 proceeds through an off-page connector 
evoked by the customer 160 (FIG. 1) to view a title. In the A 1096 to state 1120 on FIG. 20b, Returning to the decision 
presently preferred embodiment, the customer can either state 1088, if the title contains search objects that must be 
select a shortcut icon for a title on the Windows 95 desktop resolved, the process moves to a state 1098 wherein a search 
that is desired to be viewed, or after selecting the Microsoft object resolution thread is spawned. A thread is single path 
Network icon on the Windows 95 desktop, the customer 10 of execution within a process, and a process can initiate 
selects a title through the menu system of Windows 95. Of multiple threads. Using the preferred Windows 95 multi- 
course, titles may also be selected from the CD-ROM 124 threading capability this thread resolves the search objects 
(FIG. 1) or other storage 126. In any case, the bbview.exe concurrently with the states 1090-1094. This state is part of 
program, previously described, is initiated. the viewdll.dll. 

Moving to a state 1086, the process 1080 creates two data 15 In the thread started at state 1098, the process 1080 

structures: a top of a title tree and a View Block Table. The proceeds to a decision state 1100 to determine if there is a 

data structures used by the Viewer 202 are non-persistent. section (or subsection) in the title tree to process. If not, the 

This state is the InitTreeAndTable function of the CB Viewer thread ends at an end state 1110. If there is a section, as 

class and is part of viewdll.dll. The top of a title tree is the determined at state 1100, the process 1080 moves to a 

portion from the title root down to the sections (or 20 decision state 1102 and determines if there are any search 

subsections) included in the title tree, i.e., the containers in objects in the current section. If so, the process 1080 

the title tree. As an example, for the exemplary title tree 890 proceeds to state 1104 to resolve all the search objects in the 

(FIG. 17), the top of the title tree is from the title root 892 current section. This state is part of the ircl.dll. Progressing 

down through the section nodes 894, 896 and 898. An to state 1106, the process 1080 adds all the content hits (the 

exemplary Mew Block Table 920 was described in conjunc- 25 content objects found by the search objects) to the container 

tion with FIG. 18a. The View Block Table is initialized to the of the current section. This state is part of the viewdll.dll. At 

containers in the top of the title tree, beginning at the title the completion of state 1106, or if decision state 1102 

root and proceeding down each branch of the tree to a determined that no search objects were in the current 

subsection (if it exists) or a section. section, the process 1080 advances to a state 1108 and 

Continuing at a decision state 1088, the process 1080 30 attempts to access a next section in the title tree. The process 

determines whether any search objects need to be resolved 1080 then loops back to the decision state 1100 to determine 

for the customer selected title. If no search objects are to be if there is a next section in the tree. If all the sections have 

resolved, the process 1080 moves to a state 1090 and been processed, the thread completes at the end state 1110. 

determines the first section with a valid page to view. Valid This state is part of the viewdll.dll. 

pages are those that are either static, or are dynamic and have 35 Continuing now at state 1120 on FIG. 20/?, the process 

actual content (stories) to flow into them. That is, a valid 1080 composes and displays the page (determined at state 

page is one that is capable of being rendered and displayed, 1094, FIG. 20a) to view. This state is the Display View 

because the process 1080 knows and understands all of its function of the CBVIewBlocklist class and is part of 

contents. This task involves walking through the title tree viewdll.dll. State 1120 invokes state 1122 to spawn a content 

(such as tree 890, FIG. 17) to find the first page that fits one 40 acquisition thread to acquire content objects needed by the 

of the above criteria. The process 1080 begins with the top state 1120 to compose and display the current page. State 

node in the title tree 890 and does a depth-first search 1122 is part of the viewdll.dll. 

through all of the sections and subsections. For each section Moving to a decision state 1124 in the content acquisition 

(and subsection), the pages are checked in order to see if thread, the process 1080 determines if there is a section (or 

each one is valid. As soon as a valid one is found, the section 45 subsection) in the title tree to process. If not, the thread ends 

containing that page is returned as "the first section with a at an end state 1134. If there is a section, as determined at 

valid page to view". This state is the Compose function of state 1124, the process 1080 moves to a decision state 1126 

the CB Viewer class and is part of viewdlLdll and determines if there is content in the current section, 

Proceeding to a state 1092, the process 1080 navigates to including the content retrieved by the search objects at state 

the first valid section. The Viewer 202 keeps track of which so 1106 above. If so, the process 1080 proceeds to state 1128 

section is currently being viewed at any given time. This step to acquire the parse tree for each content object in the 

sets the initial value for that setting. This is done by taking section. This state is part of the viewdll.dll. Moving to state 

the section returned by the above state 1090 and writing that 1130, the process 1080 appends the acquired content parse 

value into the "Current section" setting. This state is the trees to the title tree. This state is part of the viewdll.dll. At 

GoToSection function of the CB Viewer class and is part of 55 the completion of state 1130, or if decision state 1126 

viewdll.dll. determined that there is no content in the current section, the 

Continuing at a state 1094, the process 1080 determines process 1080 advances to a state 1132 and attempts to access 

which page to view. The process 1080 also keeps track of a next section in the title tree. The process 1080 then loops 

which page is currently being displayed at any given time. back to the decision state 1124 to determine if there is a next 

This state 1094 sets the initial value for that setting. Within 60 section in the tree. If all the sections have been processed, 

the current section, the process 1080 finds the first valid the thread completes at the end state 1134. This state is part 

page, i.e., the first page that is actually capable of being of the viewdll.dll. 

rendered and displayed. This procedure is performed using To facilitate incremental delivery of a content object, the 

the same algorithm used in state 1090 above — the process MP system 100 uses a remote proxy object (not shown). The 

1080 walks through the pages in sequence, looking for either 65 proxy object allows the system to break a single object 

a static page, or a dynamic page that has content to be abstraction into multiple objects within the distributed object 

placed. This is a somewhat redundant with the code in the system. For instance, in the case of text, a title or section 
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references a text proxy object, which in effect represents a 1080 (FIG. 20a and 20b) when the Viewer 202 (bbview.exe) 

single story. The proxy object is used to separate the single is evoked by the customer 160 (FIG. 1) to view a title, 

story into multiple objects to allow the incremental delivery Moving to a state 1174, process 1170 attempts to access an 

of the story. If the story was treated only as a single object, object given an object handle from the Viewer 202. This 

then a very large story would require complete transmission 5 state ^ the Get Object function of the IObjectStore class and 

before displaying a single part of it. By use of a proxy, the ^ P arl of cos.dll. Proceeding to a decision . state 1176, 

story can be separated into multiple pieces and can then be process 1170 checks to see if the object is in a local COS 

retrieved incrementally. The title or section still interacts 1182 for the title. If so, process 1170 advances to a 

with the story object as a single entity. Proxy objects can also 5 1 a * e 1178 to instantiate object 1184 from an object stream 

be utilized with other types of content, such as images and to m . the . local C0 ^}} 81 J his s ! ate * IP*? of ^ cosdU ' 

audio The object instance 1184 is then utilized by the title viewing 

Returning to the state 1120, the Viewer 202 utilizes the P">eess 108 °; tk . . . ( t ™ ... . 

& t , . . . . j * *i_ i Returning to the decision state 1176, if the object is not in 

one or more content parse trees mat are appended to the title lhe local c g s m2 ^ mo 

moves to a state 1190 and 

toe from state 1130 and the view block table and view fequests ^ object £ Qm ^ workstation Qbject 

blocks (described in conjunction with FIGS. 18a and lSb) to is Broker gi ven an object QUID. This state is part of the 

compose and render the page. For each control on the page, objbrk.dll. Continuing at a decision state 1192, process 1170 

process 1080 calls the compose method (previously checks to see if the object is in a local superCOS 1196 on the 

described). customer workstation 182. If 80, process 1170 moves to a 

At the completion of state 1120, the process 1080 pro- state 1194 to instantiate the object 1184 from the object 

ceeds to a state 1136 and waits for a user action, such as 20 stream 1180 in the superCOS 1196. This state is part of the 

clicking on a caption button control or a picture buttoo cos.dll. The object instance 1184 is then utilized by the title 

control on the displayed page. Proceeding to a state 1138, the viewing process 1080. 

process 1080 interprets and processes the user action. This Returning to the decision state 1192, if the object is not in 

state is part of the viewdll.dll. Moving to state 1140, the the local superCOS 1196, process 1170 moves to a state 

process 1080 causes the Viewer 202 to navigate to a part of 25 1200 and preferably makes a remote request to the data 

the title indicated by the user action, such as a different center 242 (FIG. 3) for the object. This state is part of the 

section. This state is part of the viewdll.dll. Advancing to objbrk.dll. Continuing at a decision state 1202, process 1170 

state 1142, the process 1080 determines which page to view. checks to see if the object requested from the data center 242 

State 1142 is identical to state 1094 previously described. is retrieved. If so, process 1170 advances to a state 1204 to 

This state is the ResolveForm function of the CBView- 30 cache retrieved remote object 1206 in the superCOS 1196 as 

BlockList class and is part of viewdll.dll. Moving to state an object stream 1180. This state is part of the cos.dll. The 

1144, the process 1080 composes and displays the page to retrieved remote object 1206 is then utilized by the title 

view in an identical manner to that of state 1120. This state viewing process 1080. 

is the Display View function of the CBViewBlockList class Returning to the decision state 1202, if the requested 

and is part of viewdll.dll. At the completion of state 1144, the 35 object is not retrieved from the data center 242, process 1170 

process 1080 loops back to state 1136 to wait for the next moves to a state 1212 to report an "object not found" 

user action. Process 1080 continues until a user action of exception to the Viewer 202 and terminate the object 

"exit title" is selected. retrieval process 1170. This state is part of the objbrk.dll. 

2. Object Retrieval Flow CONCLUSION 

Referring now to FIG. 21, an object retrieval process 1170 40 uuw^uaiuw 

will be described. This process 1170 is performed by the This section summarizes benefits provided by the present 

Viewer 202 at the customer workstation 182 (FIG. 2) and invention. In the MP system, a content provider has a lot of 

corresponds with state 334 of the top level process 320 (FIG. flexibility to choose how a customer will view a story. In 

5), addition, the MP system is device independent in that the 

When a title is viewed, the Viewer opens a title file 45 tagged content can be displayed with high quality on many 

(having a file extension of .ttl) which represents the title. different devices. For example, a content provider can create 

This title file is a COS file. Typically in the online scenario, a title just once » but the title can be viewed on a VGA screen 

this would be a skeleton title (i.e., a COS file which contains with one column, a printer with many columns, a small 

only a root moniker and no actual objects). A local super- screen personal digital assistant (PDA), an interactive tele- 

COS is a COS file which contains subCOSes and is used to 50 vision (ITV) system, a fax machine, or a notebook computer, 

cache objects on the customer workstation 182 which have Different styles can be applied to each of these devices so 

been remotely retrieved from the MSN data center 242. As that the displayed content is formatted appropriately, 

long as these cached objects are not out of date or flushed, Moreover, separating the content and design in the MP 

the local Object Broker is able to quickly provide that object system enables sending or distributing stylized high-quality 

the next time it is requested rather than retrieving it from the 55 publications over low-speed communications links. This 

MSN data center 242 again. results from the fact that the design and style sheets of many 

The object retrieval process 1170 is utilized anytime the titles remains fairly static while only the content changes 

Viewer 202 attempts to instantiate an object which is per- regularly. The MP system does not need to send large design, 

sistently stored in the COS as a single object. The Viewer descriptions and style sheets to customers' computers unless 

202 first looks in the local COS being viewed. If the object 60 the designs or styles change. Content can typically be 

is not present, it asks the Object Broker to look in the local transmitted quickly since it consists of tagged components, 

SuperCOS (at the customer workstation 182) of cached not the actual pages and controls themselves. Thus the 

objects. If the object is not there, the Object Broker prefer- separation of design and content eliminates much of the 

ably attempts to acquire the object from the server 246 at the communication overhead in an electronic publishing envi- 

data center 242 (FIG. 3). 65 ronment. 

Beginning at a state 1172, the object retrieval process Further, the MP system supports standards such as 

1170 works in conjunction with the title viewing process Microsoft Word and Standard Generalized Markup Lan- 
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guage (SGML) to ensure that the content provider's invest- 
ment in existing tools can be fully leveraged. The MP system 
also reads standard HyperText Markup Language (HTML) 
documents so that existing HTML documents can be easily 
converted to more sophisticated applications. Additionally, 5 
through support of the OLE standard, tools that supports 
OLE server capabilities can be used to create content 
embedded in an MPS title. By supporting additional stan- 
dard file formats, the MPS can also accommodate other tools 
(for example high-end graphic applications). 

In addition to the advantages listed above, the MP system 
also has other advantages that differentiate this system from 
other on-line publishing systems. For example, graphic 
designers can work on the title and page layouts, while 
authors create content objects. There is a clean separation of 
responsibilities, with separate tools used by each profes- 15 
sional. 

Also, new content does not need to be laid out by a 
designer before it can be published. It can be uploaded to the 
distribution point and downloaded to customers' machines 
as soon as the object is completed, since the rendering is 20 
automatically done on the consumers* machines based upon 
the designs in the title's page layouts. Also, since no 
rendering has been done prior to downloading the title and 
objects to the consumer's machine, the appearance of a new 
piece of content does not force the system to re-download 25 
any other items. 

As stated above, the styles contained in every style sheet 
are predefined by the MP system authoring program. This 
program, termed the MPS Document Editor, has the special 
capability of producing documents formatted in Multimedia 30 
Publishing Markup Language (MPML). The MPML is a 
form of an SGML, but has formatting commands unique to 
the MP system. Markup languages which are well known in 
on-line networks identify portions of documents by embed- 
ded tags. In an MPML document, there is one MPML tag per 35 
document portion and each tag is mapped to a style that is 
found in a style sheet. 

Although the invention has been described with reference 
to specific embodiments, the description is intended to be 4Q 
illustrative of the invention and is not intended to be 
limiting. Various modifications and applications may occur 
to those skilled in the art without departing from the true 
spirit and scope of the invention as defined in the appended 
claims. ^ 

We claim: 

1. An electronic publication system, comprising: 

a network server having a publication storage area; 

at least one publisher computer coupled to the network 
server having a designer comprising a project editor 50 
configured to manage tiles, containers and objects; a 
page editor configured to generate title layout pages; a 
style sheet editor configured to edit style sheets; an 
object editor capable of creating search objects; and a 
word processor capable of creating content comprising 55 
tagged, hypertext documents; 

the designer on the at least one publisher computer 
configured to create a title comprising at least one of the 
title layout pages and where the title layout pages are 
linked and separated from the content; and go 

a viewer on a viewer computer coupled to the network 
server configured to retrieve the title from the network 
server's publication storage area, where the viewer 
downloads the title layout pages and the content as a 
displayable title, and the title layout pages and the 65 
content are stored in a memory area on the viewer 
computer. 



2. The system of claim 1, where the content comprises 
compound documents. 

3. The system of claim 1, where the content includes text. 

4. The system of claim 1, where the title layout pages 
comprises a plurality of page and control objects. 

5. The system of claim 1, where the title comprises an 
application. 

6. The system of claim 1, where the title comprises a 
service. 

7. The system of claim 1, where the viewer retrieves a 
portion of the title layout pages and a portion of the content 
for rendering. 

8. The system of claim 1, where the content are modified 
independently of the title layout pages. 

9. The system of claim 1, where the title layout pages are 
modified independently of the content. 

10. The system of claim 1, where the content is progres- 
sively rendered. 

11. The system of claim 1, where the generation of the title 
layout pages are performed on a first workstation and the 
rendering of the title layout pages are performed on a second 
workstation. 

12. The system of claim 1, where the viewer includes a 
query component for retrieving content matching a selected 
query criteria. 

13. The system of claim 1, where the publisher computer 
includes a structured storage for storing the title. 

14. The system of claim 1, where the viewer computer 
includes a structured storage for storing the received title. 

15. The system of claim 14, where the title layout pages 
in the viewer structured storage is replaced when new title 
layout pages for the are received from the publication 
storage area on the network server. 

16. The system of claim 1, where the title layout pages 
comprises a plurality of layout objects. 

17. A multimedia publication system, comprising: 

a publisher computer coupled to the network server 
comprising a designer environment having a project 
editor configured to manage tiles, containers and 
objects; a page editor configured to generate title layout 
pages; a style sheet editor configured to edit style 
sheets; an object editor configured to create search 
objects; and a content editor configured to edit content 
comprising tagged, hypertext documents; 

a project created by the publisher computer's project 
editor; 

a plurality of titles and content folders created by the 

publisher computer; 
layout objects created by the page editor the style sheet 

editor and the project editor; 
content objects created by the content editor; 
a server connected to the publisher computer having a 

storage area for storing the project received from the 

publisher computer; 
a customer computer connected to the server having a 

viewer for displaying the project received from the 

server storage area, where the content objects and the 

layout objects of the title axe together rendered as 

displayable portions of the project; and 
an automatic tracking system configured to track changes 

in the content objects and the layout objects. 

18. The system of claim 17, where the designer environ- 
ment additionally includes an identification process for 
assigning a unique identifier to each one of the content 
objects. 

19. The system of claim 17, where the viewer additionally 
includes an object retrieving component for retrieving the 
stored objects. 
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20. The system of claim 19, wherein the layout objects 
and the content objects are retrieved only once from the 
server storage area regardless of the number of times either 
the layout or the content is repeated in the title. 

21. The system of claim 17, where the server storage area 5 
stores a plurality of titles. 

22. The system of claim 17, where at least one of the 
content objects is a story. 

23. The system of claim 17, where at least one of the 
content objects is a picture. 10 

24. The system of claim 17, where only a portion of the 
content objects are received and displayed by the viewer. 
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25. The system of claim 17, where the viewer includes a 
query process for retrieving the content objects matching a 
selected query criteria. 

26. The system of claim 17, where the identification of the 
content objects is unique in the system. 

27. The system of claim 17, where the content objects are 
shared between the titles. 

28. The system of claim 17, where each content object has 
a unique identifier. 

29. The system of claim 17, where the content objects are 
progressively rendered. 
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